Collections Generics, internes Verhalten

[123456789]

Hallo ,

ich hätte eine Frage zu Java Generics.

Ich weiß das die Generics wegen der abwärts- Kompatibilität den Mechanismus des Type Erasure verwenden. Das heißt ja, dass zur Laufzeit keine Typinformation mehr bekannt sind und deshalb zur Kompilierzeit die Typsicherheit geprüft wird.

Und meine Frage dazu:
Wie werden dann die Werte z.B. in einer ArrayList<Integer> gespeichert? --> Als Object?

Und wenn ich folgende Liste habe:

List<Integer> intList = new ArrayList<Integer>();
intList.add(1);
Integer myInt = intList.get(0);

Zur Kompilierzeit weiß der Compiler ja dass die "intList" Integer werte beinhaltet und weiß deshalb auch, dass die Zeile 3 in Ordnung gehen muss.

Aber woher ist zur Laufzeit bekannt, dass der Wert aus intList.get(0) ein Integer ist, bzw. von Object auf Integer gecastet werden muss.

Und wie viele casts werden durch die Verwendung von Generics implizit durchgeführt?
Wie beeinflussen Generics (durch Casts) die Laufzeit?

Ich hab leider niergends eine Beschreibung dazu finden können. Meist wird nur das Type Erasure beschrieben, aber vom internen Verhalten nicht.

Wäre super wenn mir jemand weiterhelfen könnte, bzw. einen Link postet wo dieses interne Verhalten beschrieben ist.


Vielen Dank,

 

[tuttle64]

Hallo ,

ich hätte eine Frage zu Java Generics.

Ich weiß das die Generics wegen der abwärts- Kompatibilität den Mechanismus des Type Erasure verwenden. Das heißt ja, dass zur Laufzeit keine Typinformation mehr bekannt sind und deshalb zur Kompilierzeit die Typsicherheit geprüft wird.

Und meine Frage dazu:
Wie werden dann die Werte z.B. in einer ArrayList<Integer> gespeichert? --> Als Object?

Ja. Wenn Du keine Grösse angibst, legt die JVM zur Laufzeit ein Array von Object[10] an.

Wenn Du die Implementierung von get anschaust:

    public E get(int index) {
	RangeCheck(index);

	return (E) elementData[index];
    }

dann ist es so, dass zur Kompiliertzeit die E mit dem Typ den man in <E> angegeben hat ersetzt wird d.h. mit der get Methode erhält man ein Integer falls die Liste mit ArrayList<Integer> erzeugt worden ist.

 

[Fu3L]

Zur Kompilierzeit weiß der Compiler ja dass die "intList" Integer werte beinhaltet und weiß deshalb auch, dass die Zeile 3 in Ordnung gehen muss.

Aber woher ist zur Laufzeit bekannt, dass der Wert aus intList.get(0) ein Integer ist, bzw. von Object auf Integer gecastet werden muss.

Und wie viele casts werden durch die Verwendung von Generics implizit durchgeführt?
Wie beeinflussen Generics (durch Casts) die Laufzeit?

Der Compiler baut

intList.add(1);

in sowas um:

intList.add(new Integer(1));
//oder Integer.valueOf(), zu faul zu gucken, wie mans macht^^

Dadurch wird für jeden primitiven hinzugefügten Wert ein neues Objekt erzeugt. Das beeinträchtigt bei wirklich großen Zahlen (mehrere tausend) durchaus die laufzeit.
Da empfielt sich gnu-trove (kannste nach Googlen), dort gibts sowas wie TIntList, TLongList, TIntIntHashMap und so weiter^^

 

[SlaterB]

dann ist es so, dass zur Kompiliertzeit die E mit dem Typ den man in <E> angegeben hat ersetzt wird d.h. mit der get Methode erhält man ein Integer falls die Liste mit ArrayList<Integer> erzeugt worden ist.

was soll das denn bedeuten? es wird doch nicht der Quelltext von ArrayList geändert, so dass dort Integer auftaucht,
die API wird überhaupt nicht neu kompliliert, auch schwer wenn ArrayList mehrfach mit verschiedenen generischen Parametern verwendet wird

123456789 hat es selber schon richtig geschrieben, in der kompilierten Klasse ArrayList ist alles zu Object geändert, die get-Methode liefert Object zurück und fertig, ist ihr ganz egal was da drin ist,
der Cast passiert beim Aufrufer, an sich ist ziemlich leicht zu erkennen wo er hingehört, wie oft usw.,
exakte Implementations-Details sind natürlich etwas schwerer zu nennen,

die Frage richtete sich ja auch vorausschauend auf Links, von mir leider keine

 

[Marco13]

Nur nebenbei: Mit javap kann man sich den generierten bytecode einer Klasse ansehen. AFAIR wird dort gelegentlich öfter gecastet als notwendig, aber das hat auf die Laufzeit wohl keinen nennenswerten Einfluß.

 

[tuttle64]

es wird doch nicht der Quelltext von ArrayList geändert, so dass dort Integer auftaucht, die API wird überhaupt nicht neu kompliliert, auch schwer wenn ArrayList mehrfach mit verschiedenen generischen Parametern verwendet wird

Das habe ich auch nicht geschrieben.

 

[Gregorrr]

Nur nebenbei: Mit javap kann man sich den generierten bytecode einer Klasse ansehen. AFAIR wird dort gelegentlich öfter gecastet als notwendig, aber das hat auf die Laufzeit wohl keinen nennenswerten Einfluß.

Das hängt wohl mit der zu Grunde liegenden Datenstruktur zusammen. Ist sie ordentlich generisch programmiert, fällt jegliches Casten weg.

 

[Gregorrr]

Ich glaub hier liegen einige Verständnissfehler vor.

Generics sind ein statisches Mittel, dafür zu sorgen, dass der Typ zur Kompilierungszeit richtig und überall gesetzt ist. Würde man 100% generisch programmieren, könnte man komplett auf Casten verzichten, wodurch nicht mehr zur Laufzeit Castin-Exceptions auftreten würden und auch gar nicht gecastet werden müsste, ergo könnte sich das positiv auf die Laufzeit auswirken.

Ein anderes Problem hier, ist, dass int's per Autoboxing zu Integers gemacht werden. Das hat zunächst mal nichts mit Generics zu tun. Da allerdings Generics Objekte brauchen doch schon. Generell könnte ich mir vorstellen, dass Autoboxing und Unboxing so effizient implementiert sind, dass das eigentlich keinen merklichen Einfluss auf Performance haben sollte.

 

[Fu3L]

Generell könnte ich mir vorstellen, dass Autoboxing und Unboxing so effizient implementiert sind, dass das eigentlich keinen merklichen Einfluss auf Performance haben sollte.

Hats.. Bei 20.000 Elementen kannst du das subjektiv deutlich wahrnehmen und nicht nur messen...

Würde man 100% generisch programmieren, könnte man komplett auf Casten verzichten,

Ja, das bestreitet Marco auch nicht. Aber im Bytecode muss gecastet werden, weil der Interpreter in den Listen nur Objekte sieht. Generics sind nämlich nur bis zur Kompilierzeit vorhanden.

 

[Marco13]

Ist sie ordentlich generisch programmiert, fällt jegliches Casten weg.

Ja, das bestreitet Marco auch nicht. Aber im Bytecode muss gecastet werden, weil der Interpreter in den Listen nur Objekte sieht.

Genau das war gemeint.

 

[123456789]

Vielen Dank für all eure Antworten,

also es hat sich doch bestätigt, dass zur Laufzeit alle elemente generischer Listen usw. den Datentyp Object zu grunde liegen.

Bezüglich dem Casting, da muss ich mich entschuldigen, denn ich denke ich habe das unzureichend formuliert. Dazu ein kleines Bsp in pseudo code.
Würde ich meinen eigenen DataStorage (wenn auch nur für ein Element) erstellen (ohne Generics) dann würde ich, um alle Datentype unterstützen zu können eine Variable vom Typ Object benötigen.

class MyData{
   private Object data;
   private void setData(final Object data){ ...}
   private Object getData(){ ... }
}

class MyMusic{
   private String songName;
   ...
}

Dann könnte ich in MyData einen Musiktitel speichern.

class Main{
   public static void main(){
      MyData md = new MyData();
      md.setElem(new MyMusic());
      ...
      // Und ich kann den Musiktitel auch wieder abrufen, wobei aber explizit gecastet werden muss.
      // Und um genau diesen cast geht es.
      MyMusic myMusic = (MyMusic)md.getElem();

   }
}

Wenn ich einen generischen Ansatz wähle, dann würde myMusik zur Laufzeit auch als Object behandelt werden.

Aber woher ist zur Laufzeit bekannt, dass der Wert aus myMusic vom Typ MyMusic ist, bzw. von Object auf MyMusic gecastet werden muss? --> Alle Typinformationen sind ja zur Laufzeit gelöscht worden!

Danke für eure Hilfe,

 

[SlaterB]

eben weil Casts eingefügt werden, das ist doch ein einfaches Konzept

ArrayList<Integer> l = ..
Integer k = l.get(..)

wird ungefährt genau zu

ArrayList l = ..
Integer k = (Integer) l.get(..)

gehts darum?
der Kompiler streicht Generics, aber fügt gleichzeitig Casts hinzu

 

[123456789]

Vielen Dank SalterB,

ja, ich denk, das ist genau die Antwort die ich suche.
Anscheinened fange ich auch langsam an die Zusammenhänge von Generics zu verstehen
Der cast vom Kompiler kann problemlos hinzugefügt werden, da zur Kompiletime versichert wurde, dass die Liste nur zB. Integers beinhaltet. Und durch das Löschen der TypParameter sieht der, eigentlich generische Code, wieder gleich wie jener Code aus, bevor es Generics gegeben hat. Und deshalb wird die oftmals beschriebene Abwärtskompatibilität gewährleistet!

Ich glaub das war's

Vielen Dank !

 

[Gregorrr]

Hats.. Bei 20.000 Elementen kannst du das subjektiv deutlich wahrnehmen und nicht nur messen...

Danke, hab mal bisschen recherchiert, hast vollkommen Recht.

"For people that absolutely need performance, boxing and unboxing and generified collections and whatnot are big no-no's."

 

[123456789]

Hallo Gregorr,

hast du noch zufällig einen brauchbaren Link?
Wäre super wenn du den posten könntest.

Danke und lg,

 

[Marco13]

Da dürfte der Hauptaspekt aber das Boxing sein, und nicht das Casten (dass Boxing nichts für wirklich große Mengen von "primitiven" Werten in zeitktischen Programmen ist, ist bekannt)

 

[SlaterB]

"For people that absolutely need performance, boxing and unboxing and generified collections and whatnot are big no-no's"
kann man bei google eintippen

-> dieses Thema hier bereits Platz 5, davor u.a.
maintenance - Managing highly repetitive code and documentation in Java - Stack Overflow