In der letzten Ausgabe dieser Kolumne haben wir uns angesehen, wie mit Hilfe der Type Erasure Technik generische Typen in Java übersetzt werden und welche Repräsentation sie dann zur Laufzeit haben. Die Type Erasure dient in erster Linie der Kompatiblität von altem Code, der keine parametrisierten Typen verwendet, und neuen Code, der von den parametrisierten Typen in Java 5.0 Gebrauch macht. Diesmal wollen wir uns einige Konsequenzen ansehen, die sich aus der Type Erasure ergeben.

Type Erasure

• Aus einem generischen Typ wird ein nicht-generischer Typ, indem die Typparameter entfernt und durch den ersten Typ in ihrer jeweiligen Bounds-Klausel ersetzt werden. Wenn es keine Bounds-Klausel gibt, wird der Typparameter durch Object ersetzt.
• Aus einem parametrisierten Typ wird ein Raw Type, indem die Typargumente entfernt werden.
• Zusätzlich werden, wo dies nötig ist, Casts und Brückenmethoden eingefügt.

class LinkedList<A> implements List<A> {
  protected class Node {
    A elt;
    Node next = null;
    Node (A elt) { this.elt = elt; }
  }
  public void add (A elt) { ...  }
  public A get(int i) { ... }
  ...
}
final class Test {
  public static void main (String[ ] args) {
    LinkedList<String> ys = new LinkedList<String>();
    ys.add("zero"); ys.add("one");
    String y = ys.get(0);
  }
}

class LinkedList implements List {
  protected class Node {
    Object elt; Node next = null;
    Node (Object elt) { this.elt = elt; }
  }
  public void add (Object elt) { ...  }
  public Object get(int i) { ... }
  ...
}
final class Test {
  public static void main (String[ ] args) {
    LinkedList ys = new LinkedList();
    ys.add("zero"); ys.add("one");
    String y = (String) ys.get(0);
  }
}

Typisierung und Cast

• Als Java Entwickler muss man sich trotz der Einführung generischer Typen im JDK 5.0 nicht in neue Typen einarbeiten. Die neuen generischen Typen im JDK 5.0 sind die alten Typen, aber jetzt mit Typparametern, und damit ist ihre Semantik und Funktionalität unverändert geblieben.
• Man kann einen generischen Typ alternativ als Raw Type oder parametrisierten Typ nutzen. Dabei dient die Nutzung des Raw Types der Kompatibilität zu vorhandenem Legacy Code.
• Zur Laufzeit sind Raw Type und parametrisierter Typ kompatibel, so dass das Mischen von Legacy Code und neuem Code, der parametrisierte Typen nutzt, kein Problem ist.

Die Tabelle enthält in der ersten Spalte drei Variablendefinitionen mit Konstruktion und Zuweisung von Objekten. Die zweite und dritte Spalte zeigen jeweils den statischen Typ der Variable bzw. den dynamischen Typ des Objekts aus der vorhergehenden Anweisung. Der statische Typ wird vom Compiler für Prüfung bei Zuweisungen sowie bei der Übergabe von Methodenparametern und Returnwerten verwendet. Daneben wird der statische Typ vom Compiler auch zur Overload Resolution verwendet. Der dynamische Typ hingegen wird zu Laufzeitprüfungen benutzt, etwa beim Cast oder bei der Benutzung des Operators  instanceof. Typisch für Java ist, dass der dynamische Typ mindestens so exakt, wenn nicht exakter ist, als der statische Typ.

Wie sieht das Ganze nun bei parametrisierten Typen aus?  Sehen wir uns einige Beispiel mit parametrisierten Typen an:
 

Auf Grund der Type Erasure sind statischer und dynamischer Typ nie gleich. Auch ist der dynamische Typ nicht mindestens so exakt wie der statische; das kann man an den ersten beiden Anweisungen sehen. Ganz offensichtlich werden einige Regeln des Java Typsystems bei der Benutzung parametrisierter Typen neu definiert. Schauen wir uns an, was es in der Praxis bedeuet.

LinkedList<String>  refToStringList  = new LinkedList<String>();
LinkedList<Integer> refToIntegerList = new LinkedList<Integer>();
refToStringList = refToIntegerList;   // Zeile 3: inkompatibel – lässt sich nicht übersetzen

LinkedList<String>  refToStringList  = new LinkedList<String>();
Object objectRefToStringList  = new LinkedList<String>();
refToStringList = objectRefToStringList;  // Zeile 6: inkompatibel – lässt sich nicht übersetzen

LinkedList<String>  refToStringList  = new LinkedList<String>();
Object objectRefToStringList  = new LinkedList<String>();
refToStringList = (LinkedList<String>)objectRefToStringList;  // Zeile 6: lässt sich nun übersetzen

Was passiert aber, wenn die Object-Referenz in Zeile 5 gar nicht auf eine LinkedList<String> sondern auf eine LinkedList<Integer> verweist?

LinkedList<String>  refToStringList  = new LinkedList<String>();
Object objectRefToStringList  = new LinkedList<Integer>();
refToStringList = (LinkedList<String>)objectRefToStringList;  // Zeile 6: lässt sich immer noch übersetzen

Dieser Effekt ist wirklich eine Überraschung, denn zumindest für parametrisierte Typen gilt nicht mehr, dass man zur Laufzeit den exakten Typ eines Objekts ermitteln kann. Das liegt an der Type Erasure: das Typargument eines parametrisierten Typs ist zur Laufzeit nicht mehr vorhanden. Sehr pointiert kann man es mit dem folgenden Vergleich illustrieren, der immer true liefert:

(new LinkedList<Integer>()).getClass() == (new LinkedList<String>()).getClass()

Kommen wir noch einmal auf das Beispiel von oben zurück. Was passiert eigentlich, nachdem sich die Zuweisung der LinkedList<Integer> an die LinkedList<String> wegen des Casts übersetzen lässt und die dynamische Prüfung zur Laufzeit auch nicht fehlschlägt? Macht es sich irgendwie bemerkbar, dass eine Variable vom Typ LinkedList<String> auf ein Objekt vom Typ LinkedList<Integer> verweist, oder macht das gar nichts?  Stellen wir uns den weiteren Verlauf des Programms vor. Wahrscheinlich wird irgendwann auf refToStringList  zugegriffen:

LinkedList<String>  refToStringList  = new LinkedList<String>();
Object objectRefToStringList  = new LinkedList<Integer>();
// ... objectRefToStringList  mit Integer füllen ...
refToStringList = (LinkedList<String>)objectRefToStringList;
// ...
String tmpString = refToStringList.get(0);

LinkedList refToStringList  = new LinkedList();
Object objectRefToStringList  = new LinkedList();
// ... objectRefToStringList  mit Integer füllen ...
refToStringList = (LinkedList)objectRefToStringList;
// ...
String tmpString = (String)refToStringList.get(0);

Allerdings ist man als Entwickler vorgewarnt, denn der Compiler meldet eine unchecked-Warnung, wenn der Zieltyp eines Casts ein parametrisierter Typ ist.  Das heißt, auf den Cast nach LinkedList<String> in der fragwürdigen Zuweisung in unserem Beispiel wird vom Compiler ausdrücklich hingewiesen, weil der Cast im Source-Code exakter aussieht, als er zur Laufzeit nach der Type Erasure tatsächlich ausgeführt wird.  Man sollte solche unchecked-Warnungen also durchaus ernst nehmen.

Weitere Einschränkungen und Regeln

refToStringList = (LinkedList<String>)objectRefToStringList;

if (o instanceof LinkedList) …         // okay
if (o instanceof LinkedList<String>) … // Fehler beim Kompilieren

Aus ähnlichen Gründen wie oben gibt es keine Class-Literale für parametrisierte Typen, sondern nur für den Raw Type:

Class<? extends LinkedList> c1 = java.util.LinkedList.class;          // okay
Class<? extends LinkedList> c2 = java.util.LinkedList<String>.class;  // Fehler beim Kompilieren

Statische Felder und Methoden einer generischen Klasse

Schauen wir uns dazu das Beispiel eines generischen Typs mit einem statischen Feld an:

public class MyClass<T> {
  public static int cnt = 0;
   …
}

MyClass<Integer> myi = new MyClass<Integer>();
MyClass<String>  mys = new MyClass<String>();
myi.cnt++;
mys.cnt++;

Was wir hier am Beispiel des Feldes cnt besprochen haben, gilt grundsätzlich für alle statischen Felder und Methoden: das jeweilige statische Feld bzw. die jeweilige statische Methode existiert nur genau einmal für alle Parametrisierungen des generischen Typs und seinen Raw Type.

In Java ist es möglich, ein statisches Element über ein Objekt anzusprechen, zum Beispiel als: myi.cnt++. Die Anweisung führt zu einer Warnung: „The static field cnt should be accessed in a static way.” Das heißt, das Feld soll über eine Klasse statt über ein Objekt angesprochen werden. Wie macht man dass bei einer generischen Klasse? Spricht man statische Felder über den parametrisierten Typ an?  Es wäre zumindest denkbar, dass man das statische cnt-Feld des parametrisierten Typs MyClass<Integer> als MyClass<Integer>.cnt anspricht.  Das ist aber nicht zulässig. Wie beim Class-Literal und beim instanceof Operator ist nur der Raw Type zulässig:

MyClass.cnt++; // okay
MyClass<String>.cnt++;  // Fehler beim Kompilieren
MyClass<Integer>.cnt++; // Fehler beim Kompilieren

Es gibt noch  eine weitere gravierende Einschränkung bei generischen Typen und statischen Elementen: ein Typparameter des generischen Typs darf nicht in der Definition von statischen Feldern oder statischen Methoden verwendet werden. Das bedeutet, dass die folgenden drei Definitionen Fehler beim Kompilieren liefern:

public final class X<T> {
  private static T field;                           // Fehler beim Kompilieren
  public  static T getField() { return field; }     // Fehler beim Kompilieren
  public  static void setField(T t) { field = t; }  // Fehler beim Kompilieren
}

Das bedeutet aber nicht, dass statische Methoden nicht generisch sein können. Ganz im Gegenteil. Es gibt viele Beispiele für generische, statische Methoden. Zum Beispiel die Methoden der Klasse java.util.Collections:

class Collections {
   public static <T> void sort(List<T> list, Comparator<? super T> comp);
   // ... und so weiter ...
}

Unterschiede zwischen generischen Typen und normalen Referenztypen zur Laufzeit

Schaut man sich diese Interfaces einmal genauer an, so stellt man fest, dass sich die Information, die man über diese Interfaces bekommt, nicht auf den Laufzeittyp der Typparameter bezieht. Was man erfragen kann, sind vielmehr die Details des formalen Typparameters eines generischen Typs. So liefert zum Beispiel TypeVariable<D>.getBounds() die Typen der Boundsklausel und TypeVariable<D>.getName() den Namen des Typparameters im Sourcecode. Schauen wir uns dazu ein Beispiel an:

LinkedList<String> l = new LinkedList<String>();

TypeVariable tp = (l.getClass().getTypeParameters())[0];

System.out.println("name: " + tp.getName());

Type[] types = tp.getBounds();
if (types[0] instanceof Class)
  System.out.println("classname: " + ((Class)types[0]).getName());

name: E
classname: java.lang.Object

Wie man sieht, ist diese Information nicht dazu geeignet, etwas über den aktuellen Typparameter unserer LinkedList<String> zu erfahren.  Was man über Reflection erhält, ist ausschließlich statische Typinformation.

Zusammenfassung

• Bei parametrisierten Typen ist der aktuelle Typparameter zur Laufzeit nicht mehr vorhanden. Das heißt, dass man die typische Java-Programmiertechnik, den vollständigen Typ zur Laufzeit durch Cast, instanceof, usw. zu ermitteln, nicht problemlos einsetzen kann. Siehe dazu unser Beispiel aus dem Absatz „Typisierung und Cast“.
• Um deutlich zu machen, dass es zur Laufzeit nur eine Repräsentation für einen generischen Typ gibt, die für alle Parametrisierungen und den Raw Type relevant ist, darf man an vielen Stellen, an denen auf die Repräsentation verwiesen wird, nur den Raw Type und keinen parametrisierten Typ benutzten. Diese Stellen sind Class-Literale, instanceof-Operator und der Zugriff auf statischen Felder und Methoden.

Literaturverweise und weitere Informationsquellen

Die gesamte Serie über Java Generics:

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Effective Java - Java best practice programming techniques, common pitfalls, and off-the-beaten-path language features 4 day seminar ( open enrollment and on-site)