Generics - Type erasure

[Tarrew]

Hey, ich habe grade ein bisschen Probleme bei der Typersetzung des Compilers bezüglich Java Generics.
Ich habe beispielsweise folgende Klassen:

public class Foo implements Comparable<Foo>{
int wert;

public Foo(int x) {
	wert=x;
}
	@Override
	public int compareTo(Foo o) {
		return wert-o.wert;
	}
	
	public static <E extends Comparable<? super E>> E[] bubbleSort(E[] array) {
        for(int iter =1; iter< array.length; iter++){
            for(int inner = 0; inner < (array.length - iter); inner ++){
                if((((array[inner])).compareTo(array[inner+1])) > 0){
                    E tmp = array[inner];
                    array[inner] = array[inner + 1];
                    array[inner + 1] = tmp;
                }                
            }
        }
        return array;
    }

}

und

public class Bar extends Foo {

	public Bar(int x) {
		super(x);
	}

}

Jetzt kann ich (trivialerweise) folgenden Aufruf machen:

      Foo[] fooArray = new Foo[10];
		for(int i=0; i<10; i++){
			fooArray[i]=new Foo(random.nextInt(50));
		}
		Foo[] fooArray2 = Foo.bubbleSort(fooArray);

(Ich weiß, das Originalarray wird schon geändert, ich returne nur nochmal das Array und speicher es erneut in einer anderen Variable um mein Problem mit den Rückgabewerten zu veranschaulichen).

Folgender Aufruf schlägt (auch trivialerweise) fehl:

                Bar[] barArray = new Bar[10];
		for(int i=0; i<10; i++){
			barArray[i]=new Bar(random.nextInt(50));
		}
	
		Bar[] barArray2 = Foo.bubbleSort(barArray);

Das kann ja nicht gehen, weil Bar nicht Comparable<Bar> implementiert und deswegen der generische Typ "E" nicht auf Bar gesetzt werden kann weil sonst die Methodensignatur nicht mehr passt.

Jetzt ist es aber so, dass folgende Zeile klappt:

Foo[] fooArray2 = Foo.bubbleSort(barArray);

Mit dem barArray genau wie im vorigen Beispiel erzeugt.

Wie kann man sich das vorstellen. Der Compiler versucht erst, den generischen Typen auf "Bar" zu setzen und merkt, dass das nicht funktioniert. Dann probiert ers mit der Oberklasse "Foo" und merkt das passt oder wie läuft das?

Ich hatte die Frage schonmal woanders gestellt, da ging die letzte Zeile nicht durch und es kam ein "Bound mismatch". Ist das irgendein "Feature" aus einer neuen Java-Version oder so?

Hoffe mir kann jemand erklären, was da genau passiert, wie dieser generische Typ ersetzt wird.
Ich hab ja meine Vermutung geäußert bin allerdings verwirrt, dass es bei jemand anderem nicht kompiliert hat.

Grüße

 

[CSHW89]

Folgender Aufruf schlägt (auch trivialerweise) fehl:

                Bar[] barArray = new Bar[10];
		for(int i=0; i<10; i++){
			barArray[i]=new Bar(random.nextInt(50));
		}
	
		Bar[] barArray2 = Foo.bubbleSort(barArray);

Das kann ja nicht gehen, weil Bar nicht Comparable<Bar> implementiert und deswegen der generische Typ "E" nicht auf Bar gesetzt werden kann weil sonst die Methodensignatur nicht mehr passt.

Warum sollte das fehlschlagen? Hast du es getestet? Bei mir funktioniert das sowohl mit Java 7 als auch mit 8. Die Sache ist, wenn E = Bar ist, muss E nicht Comparable<Bar> implementieren, sondern Comparable<? super Bar>. Und das tut es, denn Bar implementiert Comparable<Foo> und Foo ist eine Superklasse von Bar.
Ob die compareTo-Funktion von Foo noch korrekt mit Bar-Objekten arbeitet, oder sie doch von Bar überschrieben werden sollte, ist eine andere Frage, aber nicht die des Compilers .

lg Kevin

 

[Tarrew]

Ach Mist, danke das du mich drauf hinweist.

Das war schon mein "korrigierter Code", in echt sollte da stehen ..."extends Comparable<E>.
Kann den Beitrag leider nicht mehr editieren.

Also die Klasse Foo sieht so aus:

public class Foo implements Comparable<Foo>{
int wert;
 
public Foo(int x) {
	wert=x;
}
	@Override
	public int compareTo(Foo o) {
		return wert-o.wert;
	}
 
	public static <E extends Comparable<E>> E[] bubbleSort(E[] array) {
        for(int iter =1; iter< array.length; iter++){
            for(int inner = 0; inner < (array.length - iter); inner ++){
                if((((array[inner])).compareTo(array[inner+1])) > 0){
                    E tmp = array[inner];
                    array[inner] = array[inner + 1];
                    array[inner + 1] = tmp;
                }                
            }
        }
        return array;
    }
 
}

 

[CSHW89]

Ah ja das ist wirklich interessant. Die Variante "Bar[] barArray2 = Foo.bubbleSort(barArray);" gibt bei Java 7 und 8 einen Fehler, allerdings aus unterschiedlichem Grund. Und die Variante "Foo[] fooArray2 = Foo.bubbleSort(barArray);" gibt nur bei Java 7 einen Fehler.

Ok, ich denke Java 7 sagt sich hier "Bar[] barArray2 = Foo.bubbleSort(barArray);" das Argument ist vom Typ Bar[], also muss E = Bar. Danach merkt der Compiler, dass das Argument nicht die notwendige Eigenschaft hat, und gibt ein "Bound mismatch" aus.

Java 8 ist da wohl etwas intelligenter und sagt sich, das Argument ist vom Typ Bar[], also muss E = Bar oder irgendeine Superklasse davon sein, denn das Argument würde ja auch darein passen. Dabei merkt der Compiler dann, dass Bar nicht passt, ein Supertyp, nämlich Foo aber sehr wohl. Also setzt er E = Foo und der Rückgabetyp ist Foo[]. Deshalb quitiert er die erste Variante dann mit einem "Type mismatch: cannot convert from Foo[] to Bar[]", und lässt die zweite Variante durch.

Ich hatte vor kurzen mal etwas dazu gelesen, dass auf Grund der Lambdas in Java 8 der Compiler etwas intelligenter bei der Type inference agiert. Hier macht sich das dann auch bemerkbar.

lg Kevin

 

[Tarrew]

Hey, ich melde mich nochmal. Erstmal Danke für die Erläuterung. Das macht für mich auch erstmal Sinn.

Hab dann grad durch Zufall was festgestellt:
Ich habe eine generische Klasse "Tier":

public abstract class Tier<T extends Tier<T>> {

}

Dann noch eine Klasse Katze:

public class Katze extends Tier<Katze> {

}

und dazu noch eine Klasse Hauskatze, die einfach nur eine Unterklasse von Katze ist.

Zu guter Letzt die Klasse Käfig:

package main;

public class Käfig<T extends Tier<T>> {

	T inhalt;

	public void add(T tier) {
		inhalt = tier;
	}
	
	public <E extends Tier<E>>void add2(E tier){
		E lokalerInhalt;
		lokalerInhalt = tier;
	}

	public T remove() {
		T result = inhalt;
		inhalt = null;
		return result;
	}
	

	public static void main(String[] args) {
		Käfig<Katze> k = new Käfig<Katze>();
		k.add(new Katze());
		k.add(new Hauskatze()); 
		k.add2(new Hauskatze());		
	}
	
}

So, das komische ist unter Java7 schlägt der k2.add Aufruf natürlich fehl, wie schon erläutert wurde.
Das Komische ist, dass "k.add(new Hauskatze()); " auch unter Java7 schon funktioniert.

Im Prinzip ist es ja genau das gleiche. Nur das einmal der generische Parameter T auf Klassenebene "erzeugt" wird und einmal auf Methodeneben (falls man das so sagen kann).

Jedenfalls sollten T und E genau die gleichen Klassen 'einschränken'.
Wie kommt es, dass der k.add(new Hauskatze()); geht und der k.add2(new Hauskatze()); fehlschlägt.

Anscheinend war Java7 ja schon schlau genug zu merken, dass Hauskatze auch als Parameter akzeptiert wird, obwohl der Parameter "T" ist, und T ja das Interface "direkt" implementiert.

Sobald man das gleiche macht mit einem generischen Parameter in einer Methode wird eine Hauskatze nicht akzeptiert. Vllt hat da jemand eine Erklärung zu.

Danke

 

[CSHW89]

Du erstellst einen Käfig mit T=Katze. Somit ist die Signatur von add auf jeden Fall schon vorgegeben: "add(Katze tier)". Und da eine Hauskatze auch eine Katze ist, funktionierts. add2 funktioniert mit Hauskatze ja deshalb nicht, weil Java selbst das E bestimmen muss, und es fälschlicherweise auf Hauskatze setzt.

lg Kevin