Generics casten

[Javt]

Hi,

Ich bin jetzt wirklich verwirrt. Folgendes ist nicht gestattet:

MyList<Object> l1 = new MyList<String>();

aber folgendes schon:

MyList l2 = new MyList<String>();

--> letztendlich sind die Elemente von "l2" dann vom Typ "Object". Das kann doch nicht sein. Wieso ist das eine erlaubt, das andere nicht? Ich mein im Grunde sind beide dasselbe? Bzw. wieso ist denn dann das zweite "l2" nicht vom Typ "String"?

lg

 

[HoaX]

Das erste ist nicht erlaubt, da du ja sonst z.B. einen Integer in die Liste einfügen könntest, obwohl die Liste aber eigentlich nur String zulässt.

Beim Zweiten solltest du eine entsprechende Warnung bekommen beim Kompilieren dass es unsicher ist.

 

[Javt]

Ja aber das was mir nicht einleuchtet ist: Sowohl l1 als auch l2 sind eigentlich vom selben Typ "Object". Die zweite Liste l2 ist ja auch vom Typ "Object" letztendlich. Das was du sagst sollte für den zweiten Fall doch auch gelten, dass ich eine Liste vom Typ String anlege und versuchen könnte über l2 nicht-Strings in die Liste einzufügen?

 

[Gast2]

Bei der zweiten Variante verwendest du den Rawtype, das sollte man bei Java >= 1.5, wie auch schon im anderen Thread erwähnt, nicht mehr tun. Eben weils zu Problemen kommen kann wenn du plötzlich andere Objekte in die Liste steckst.

EDIT:
Da haben sich unsere Antworten grad überschnitten.

Sowohl l1 als auch l2 sind eigentlich vom selben Typ "Object".

l1 ist vom Typ List<Object>, l2 ist vom Typ List, das ist nen kleiner aber feiner Unterschied.

Das was du sagst sollte für den zweiten Fall doch auch gelten, dass ich eine Liste vom Typ String anlege und versuchen könnte über l2 nicht-Strings in die Liste einzufügen?

Nein, wenn du den Rawtype verwendest kann Java nicht wissen was für eine Liste du da tatsächlich hast, daher darfst du alles einfügen. Hast du stattdessen eine List<Object> weiß Java dass nur Instanzen vom Typ Object reindürfen.

 

[Javt]

Also manches in Java ist schon sehr merkwürdig. Nurweil es "RawType" ist, ist das was bei Generics verboten ist zugelassen und man darf schlampen.

 

[Gast2]

Und wieder überschnitten...
Vor Java 1.5 gabs noch gar keine Generics, daher kommt der (Raw)Type List. Da musste man noch selbst dafür sorgen dass das was man in die Liste packt auch darein darf. Seit den Generics hilft einem da der Compiler. Den Rawtype musste man drin lassen, damit alte Programme kompatibel bleiben.

 

[Spacerat]

Beim ersteren hätte die List<String> etwas gegen das Einfügen von Objects, deswegen funktioniert es nicht (@edit: schlampereien mit RawType würde ich mir deswegen auch schenken, dann hagelts irgendwann Exceptions). Beim zweiten fehlt schlicht die Typisierung, das gibt 'ne Warnung. Um es ohne Warnung hinzubekommen, sollte es

MyList<?> l1 = new MyList<String>();

tun, aber einer solchen Liste liessen sich nur null-Objekte hinzufügen.

 

[xehpuk]

schlampereien mit RawType würde ich mir deswegen auch schenken, dann hagelts irgendwann Exceptions

Afaik löscht der Compiler sämtliche Generics-Informationen, wenn ein Rawtype verwendet wird. Von daher dürfte nie eine Exception fliegen.

Läuft problemlos durch:

public class GenericsVsRaw {
	public static void main(final String[] args) {
		addAndPrint(new ArrayList<Void>());
		addAndPrint(new ArrayList<Integer>());
		addAndPrint(new ArrayList<String>());
		addAndPrint(new ArrayList<Object>());
	}
	
	static void addAndPrint(final List list) {
		add(list);
		print(list);
	}

	static void add(final List list) {
		list.add(new Object());
		list.add('C');
		list.add(1.337);
		list.add(null);
		list.add("S");
		list.add(42);
	}

	static void print(final List list) {
		for (final Object o : list) {
			System.out.println(o);
		}
	}
}

 

[Gast2]

Du stellst in dem Beispiel ja auch nichts sinnvolles mit der Liste an. Wenn du irgendwann mal versuchst aus der Liste was konkretes rauszuholen fliegt dir ne ClassCastException wenns nicht vom erwarteten Typ ist.

 

[Spacerat]

@Xepuk: Oh doch, da fliegt eine... z.B. wenn man nach "add(0, object)" ein "String string = (String) get(0)" versucht. Das ist prähistorisch... wozu gibt es eigentlich diese Generics? XD Im übrigen verwirft der Compiler sämtliche Generics. Decompilier mal eine Java1.5+ Klasse.

@EikeB: War isch langsam, nisch wahr?

 

[xehpuk]

Ich meinte damit, dass keine versteckte Exception fliegt. Dass beim expliziten Cast eine fliegen kann, ist klar.

Im übrigen verwirft der Compiler sämtliche Generics.

Kommt drauf an, was du darunter verstehst. Wenn im Bytecode ein (sicherer) Cast eingefügt wird, ist das für mich schon kein "Verwerfen".

Andererseits können sie auch "richtig" hinterlegt werden. Gib

javac

mal den Parameter

-g

mit. Dann werden die

Code

-Attribute auch jeweils ein

LocalVariableTypeTable

-Attribut haben. Dort finden sich die Typparameter in der angegebenen Signatur wieder.
Hat dann zwar keine Auswirkung auf die Ausführung des Codes durch die JVM, ist aber für Debugger oder Decompiler nützlich.

[EDIT]Und dass der Decompiler, den du genutzt hast, dieses Attribut nicht berücksichtigt, ist dessen Manko. Würde mich bei solchen Aussagen also nicht auf Decompiler verlassen. JD-GUI kriegts auch nicht gebacken. Wird Zeit, dass ich mich auch mal an einen ransetze. [/EDIT]

 

[hüteüberhüte]

<Object>

ist !=

<String>

. Bei Generics ist es nicht erlaubt, einen Supertyp anzugeben

 

[Spacerat]

[EDIT]Und dass der Compiler, den du genutzt hast, dieses Attribut nicht berücksichtigt, ist dessen Manko. Würde mich bei solchen Aussagen also nicht auf Decompiler verlassen. JD-GUI kriegts auch nichts gebacken. Wird Zeit, dass ich mich auch mal an einen ransetze. [/EDIT]

Dieses Attribut kann man nur berücksichtigen, wenn es im Bytecode steht und das ist nur bei Entwicklungsklassen (z.B. denen des JDK) der Fall. Distributionen (z.B. Klassen der JRE) haben diese Infos jedoch nicht. Fakt bleibt aber, dass die JVM nach wie vor komplett ohne Generics auskommt, da muss auch nichts gecastet werden, weil der Bytecode von javac bereits überprüft wurde. Generics nicht dekompilieren zu können wäre demnach also kein Manko.
Wie, du willst einen eigenen Decompiler entwickeln? Schau dir mal Jasper an. Neben JD-Gui gibt's auch noch IDA-Pro, aber der disassembled glaub' ich auch nur.

 

[xehpuk]

Dieses Attribut kann man nur berücksichtigen, wenn es im Bytecode steht

Ja, wird es bei JD-GUI aber nicht.

Distributionen (z.B. Klassen der JRE) haben diese Infos jedoch nicht.

Diese haben zumindest das

Signature

-Attribut an Klassen, Methoden und Feldern kleben. Dieses Attribut wird selbst dann generiert, wenn man

javac

ein

-g:none

mitgibt.

Fakt bleibt aber, dass die JVM nach wie vor komplett ohne Generics auskommt, da muss auch nichts gecastet werden, weil der Bytecode von javac bereits überprüft wurde.

Wie meinst du das genau? Aus Generics werden letztendlich Casts (

checkcast

-Instructions) im Bytecode.

Source:

public static String generic() {
	return new java.util.ArrayList<String>().get(0);
}

Kompiliert mit

javac -g:none

und disassembliert mit

javap -c

:

public static java.lang.String generic();
  Code:
     0: new           #2                  // class java/util/ArrayList
     3: dup
     4: invokespecial #3                  // Method java/util/ArrayList."<init>":()V
     7: iconst_0
     8: invokevirtual #4                  // Method java/util/ArrayList.get:(I)Ljava/lang/Object;
    11: checkcast     #5                  // class java/lang/String
    14: areturn

Wie, du willst einen eigenen Decompiler entwickeln? Schau dir mal Jasper an. Neben JD-Gui gibt's auch noch IDA-Pro, aber der disassembled glaub' ich auch nur.

Sieht so aus, als würden beide nur disassemblieren. Bin es irgendwie leid, dass es keinen aktuellen und bugfreien Decompiler gibt (oder ich war bei der Suche bisher nicht erfolgreich). Mit einem eigenen Disassembler bin ich auch fast fertig (jaja, da gibts auch schon so Projekte wie BCEL und ASM, will mich aber nicht auf deren Weiterentwicklung verlassen und nebenbei auch einen Lerneffekt mitnehmen).

 

[Spacerat]

Der Code hat gar nichts mehr von Generics, so mein ich das. Wär' ja auch was, wenn's anders wär. Pre 1.5er Javacode liesse sich ja sonst kaum mehr ausführen.

public static String notGeneric() {
	return (String) new java.util.ArrayList().get(0);
}

public static java.lang.String notGeneric();
     0  new java.util.ArrayList [16]
     3  dup
     4  invokespecial java.util.ArrayList() [18]
     7  iconst_0
     8  invokevirtual java.util.ArrayList.get(int) : java.lang.Object [19]
    11  checkcast java.lang.String [23]
    14  areturn