Problem mit Generics

[miasma]

Hallo,

ich habe ein Problem mit generics:

@SuppressWarnings("unchecked")
final RecordPageContainer<UnorderedKeyValuePage> container = mNodeLog
	.isPresent() ? mNodeLog.get().get(key)
	: (RecordPageContainer<UnorderedKeyValuePage>) RecordPageContainer.EMPTY_INSTANCE;
if (container.equals(RecordPageContainer.EMPTY_INSTANCE)) {
  return getRecordPageContainer(key, PageKind.NODEPAGE);
} else {
  return container;
}

wieso ist da der generic type nicht übereinstimmend?

/**
 * Get a the record page container with the full/modified pages from the page
 * layer, given the unique page key and the page kind.
 * 
 * @param key
 *          {@code key} of key/value page to get the record from
 * @param pageKind
 *          kind of page to lookup
 * @return {@code the node} or {@code null} if it's not available
 * @throws SirixIOException
 *           if can't read recordPage
 * @throws NullPointerException
 *           if {@code pageKind} is {@code null}
 * @throws IllegalArgumentException
 *           if {@code key} is negative
 */
<K extends Comparable<? super K>, V extends Record, S extends KeyValuePage<K, V>> RecordPageContainer<S> getRecordPageContainer(
		@Nonnegative long key, @Nonnull PageKind pageKind)
		throws SirixIOException;

und

public final class UnorderedKeyValuePage implements KeyValuePage<Long, Record>

Sollte doch von den generic "bounds" übereinstimmen und demnach sollte ein (impliziter) cast funktionieren?

Die konkrete Meldung ist:

Type mismatch: cannot convert from RecordPageContainer<capture#7-of ? extends KeyValuePage<? extends Comparable<? super K>,Record>> to RecordPageContainer<UnorderedKeyValuePage>

und KeyValuePage ist definiert als:

/**
 * Key/Value page.
 * 
 * @author Johannes Lichtenberger
 * 
 */
public interface KeyValuePage<K extends Comparable<? super K>, V extends Record> extends Page

 

[Spacerat]

Warum ist den dort das "<? super K>" bei Comparable? genügt da nicht einfach "Comparable<K>"? Wildcards in solchen Geschichten können einen schon fast zum Wahnsin treiben. Hatte ich vor kurzem auch (http://www.java-forum.org/allgemeine-java-themen/144387-generisches-generve.html). Manchmal hilfts, wenn man entweder die generischen Klassen ebenso mit Wildcards zupflastert oder die Wildcards schlicht aus den problematischen Methoden entfernt, jedenfalls laden Generics stets zum Experimentieren ein. Mir scheint, als gäbe es hier keine richtigen Lösungen, sondern nur funktionierende (siehe Landeis Kommentar in meinem Thread).

 

[miasma]

Comparable ist ja ein Consumer, also ist super schon richtig, müsste aber nochmal in Effective Java nachlesen. Aber ich nehme an ansonsten könnte man halt keine super-Typen von dem eigentlichen Typ vergleichen. Aber daran wird der Fehler zu 99,9% nicht liegen nehme ich an.

 

[Spacerat]

Kann was ganz banales sein. Evtl. pickiert er sich ja, weil [c]UnorderedKeyValuePage[/c] vom Typ [c]KeyValuePage<Long, Record>[/c] statt vom Typ [c]KeyValuePage<? super Long, Record>[/c] ist (was natürlich afaik gar nicht geht, weil Long final ist). Andererseits stimmt das Konstrukt wohl auch nicht, weil Long ein [c]Comparable<Long>[/c] und kein [c]Comparable<? super Long>[/c] ist. Demnach wäre also das <? super K> bei der Definition des Interfaces KeyValuePage falsch.

 

[Marco13]

Das ganze in EINEM minimalen Codeschnpsiel zusammengefasst, der NUR das Problem zeigt, wäre handlicher...

 

[miasma]

Kann ich leider nicht extrahieren, aber die relevanten Sachen habe ich jetzt auch nochmal in

java - generics inferred types not valid - Stack Overflow

gepostet. Lässt mich nicht schlafen sowas ;-)

Achja, wegen Comparable, wie gesagt das ist ein Consumer nach PECS von Josh Bloch:

Effective Java: A Programming Language Guide - Joshua Bloch - Google Books

Das muss im Prinzip passen...

 

[Spacerat]

...Das muss im Prinzip passen...

Hört sich nach "Pflichtenheft" an, okay.
Nun weis ich nicht, was deine Methode oben zurück geben soll (geschweige denn wie sie heisst und in welcher Klasse sie ist), aber analog zu meinem Problem funktioniert bei dir folgendes:

interface Page {
	
}

interface Record {
	
}

interface KeyValuePage<K extends Comparable<? super K>, V extends Record> extends Page {
	
}

interface UnorderedKeyValuePage extends KeyValuePage<Long, Record> {
	
}

interface RecordPageContainer<C extends KeyValuePage<?, ?>> {
	RecordPageContainer<?> EMPTY_INSTANCE = null;
}

interface PageKind {
	PageKind NODEPAGE = null;
}

class SomeClass {
	@SuppressWarnings("unchecked")
	<K extends Comparable<? super K>, V extends Record, S extends KeyValuePage<K, V>> RecordPageContainer<S> someMethod() {
		final RecordPageContainer<UnorderedKeyValuePage> container = (RecordPageContainer<UnorderedKeyValuePage>) RecordPageContainer.EMPTY_INSTANCE;
		if (container.equals(RecordPageContainer.EMPTY_INSTANCE)) {
		  return (RecordPageContainer<S>) getRecordPageContainer(0L, PageKind.NODEPAGE);
		}
		return (RecordPageContainer<S>) container;
	}

	<K extends Comparable<? super K>, V extends Record, S extends KeyValuePage<K, V>> RecordPageContainer<S> getRecordPageContainer(long key, PageKind pageKind) {
		return null;
	}
}

... nicht schön aber selten.

 

[miasma]

Komisch, was ist denn da der Unterschied zu meinem Ansatz? Ich habs jetzt mit explizitem Casten gelöst. Vielen Dank für deine Mühe. Jetzt kann man es sich auf

https://github.com/JohannesLichtenb...in/java/org/sirix/access/PageReadTrxImpl.java

anschauen, ich wollte halt nur nicht, dass ich den trunk versaue und travis meckert ;-) Naja, zu früh gefreut, in Eclipse liefen die Unit tests durch...

 

[miasma]

Ok läuft 🙂

 

[Spacerat]

Komisch, was ist denn da der Unterschied zu meinem Ansatz?

Gibt anscheinend keinen, ich hatte deinen ja auch vorher nicht gesehen (deswegen SomeClass, someMethod). Was ich gesehen habe war eine Frage, wie man es entweder besser machen kann oder zumindest zum Laufen bekommt. Der Trick lag halt (wie bei mir auch) ganz einfach im expliziten casten und dem Rückgabewert der aufrufenden Methode (welcher für mich halt auch unbekannt war), ich denke mal, das ist das, was Landei bei mir mit "in den Hintern beissen" meinte. Aber was soll's, es geht ja und das ist wichtig.

 

[miasma]

Bei SO meinte jemand das wäre misuse von Generics, aber mir gehts ja nur um den return type, dass der wirklich generisch ist und ich im Prinzip jede KeyValuePage (bspw. jetzt für einen B+-Baum Index verwenden kann), und für eine andere Methode brauche ich auch den genauen Key und Value Typ, also muss mit "K" und "V" innerhalb der Methode arbeiten, deshalb sehe ich nicht wieso das ein misuse wäre:

But there's a larger misuse of generics here - how does the method implementation actually guarantee those type parameters are correct?

Der Methode ist es ja im Prinzip völlig egal, hauptsache die Page als Rückgabewert passt.

Bspw. sieht die Implementierung der Methode so aus:

	@Override
	public <K extends Comparable<? super K>, V extends Record, S extends KeyValuePage<K, V>> RecordPageContainer<S> getRecordPageContainer(
			final @Nonnull @Nonnegative Long recordPageKey,
			final @Nonnull PageKind pageKind) throws SirixIOException {
		assertNotClosed();
		checkArgument(recordPageKey >= 0, "recordPageKey must not be negative!");
		final List<S> revs = (List<S>) this.<K, V, S>getSnapshotPages(
				checkNotNull(recordPageKey), checkNotNull(pageKind));
		if (revs.size() == 0) {
			return RecordPageContainer.<S>emptyInstance();
		}

		final int mileStoneRevision = mResourceConfig.mRevisionsToRestore;
		final Revisioning revisioning = mResourceConfig.mRevisionKind;
		final S completePage = revisioning.combineRecordPages(revs,
				mileStoneRevision, this);
		return new RecordPageContainer<S>(completePage);
	}