In den letzten zwei Ausgabe dieser Kolumne haben wir das in Java 5.0 neue Sprachmittel der generischen Typen (Java Generics) vorgestellt.  Nach einer allgemeinen Einleitung im ersten Beitrag haben wir uns im zweiten Beitrag Wildcard-parametrisierte Typen angesehen. In diesem Beitrag wollen wir uns näher mit dem Raw Type beschäftigen sowie mit der Kompatibilität von neuem Java Code, der parametrisierte Typen verwendet, und Legacy Code, der keine parametrisierten Typen verwendet.

Der Raw Type

Da nun in der JavaDoc des JDK 5.0 die java.util.List<E> als generischer Typ mit Typparameter E beschrieben ist, muss man sich eigentlich fragen, wo das gute, alte nicht-generische Interface java.util.List geblieben ist. Die Frage stellt sich insbesondere dann, wenn man das Interface noch in vorhandenem Code verwendet, wie zum Beispiel hier:

List myList = new ArrayList();
myList.add("Hello World!"); // Zeile 2

Eine Menge Fragen - kommen wir zu den Antworten. In allen Fällen, in denen mit dem JDK 5.0 ein generischer Typ einen nicht-generischen ersetzt hat, z.B. List<E> statt List, gibt es heute nur noch den generischen Typ. Jetzt kann man den generischen Typ aber nicht nur parametrisieren, um ihn zu verwenden, z.B. als List<String> oder List<Integer>, vielmehr kann man auch den Raw Type des generischen Typs, nämlich List, verwenden. Das macht man ganz automatisch, wenn man Legacy Code wie in unserem Beispiel oben, mit dem JDK 5.0 übersetzt.

Die Kompatibilität mit bestehendem Legacy Code ist der Hauptgrund, warum der Raw Type überhaupt als mögliche Verwendung eines generischen Typs zugelassen wurde. Oder anders ausgedrückt: mit Hilfe des Raw Types war es nicht nötig, mit dem JDK 5.0  einen vollständig neuen generischen Collection-Framework zu definieren. Stattdessen hat man bei Sun den alten Framework mit allen Interfaces und Klassen hergenommen und diese sinnvoll in generische Typen überführt. Dies gilt nicht nur für den Collection-Framework, sondern für alle Klassen des JDK. So ist zum Beispiel im JDK 5.0 sogar java.lang.Class<T> ein generischer Typ. Die Kompatibilität mit vorhandenem Legacy Code ist eine wichtige Voraussetzung für die Akzeptanz der generischen Typen in der Java Community. Jeder Entwickler kann parametrisierte Typen in dem Maße benutzen,  wie er möchte: entweder er nutzt sie als parametrisierten Typ wie List<String> oder als Raw Type wie List. Mit dem Raw Type ist wieder alles so wie vor dem JDK 5.0, so dass jeder Entwickler im Grunde die Möglichkeit hat, Java Generics mehr oder weniger zu ignorieren.

Dabei ist die Nutzung des Raw Types, d.h. der Verzicht auf parametrisierte Typen, in neuen Implementierungen keine gute Alternative: man verliert die Typprüfung durch den Compiler und damit den wesentlichen Vorteil von generischen Typen. Der Compiler weist auch darauf hin. Wenn man das Beispiel von oben übersetzt, wird zwar Code erzeugt, aber beim Compilieren meldet der Compiler für die Zeile 2 eine sogenannte unchecked warning.

List myList = new ArrayList();
myList.add("Hello World!"); // unchecked warning

List<String> myList = new ArrayList<String>();
myList.add("Hello World!");  // fine

In Legacy Code verwendet man automatischen den Raw Type und in neuen Implementierungen soll man stattdessen parametrisierte Typen verwenden.  Das wirft unweigerlich neue Fragen auf: Wie funktioniert das an der Schnittstelle zwischen neuem und altem Code? Kann man einen parametrisierten Typ an eine Methode übergeben, die einen Raw Type verlangt? Und umgekehrt? Wie funktioniert das bei Zuweisungen?

Auch hier muss es ein hohes Maß an Kompatibilität geben, denn sonst könnten parametrisierte Typen erst einmal nur auf neu implementierten ‚Inseln’ verwendet werden.  Entsprechend hatte die Kompatibilität zwischen Raw Type und parametrisieren Typen bei der Entwicklung der generischen Typen durch Sun oberste Priorität. Im Folgenden wollen wir uns ansehen, wie diese Kompatibilität erreicht wird. Danach kommen wir noch einmal auf das Thema „Kompatibilität von Raw Type und parametrisiertem Typ“ zurück und diskutieren die Details ausführlich. Im nächsten Artikel beschäftigen wir uns mit den Konsequenzen und Einschränkungen dieser Ansatzes.

Type Erasure

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) { ... }
  ...
}

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) { ... }
  ...
}

• Die Typparameter werden entfernt und durch den ersten Typ in ihrer Bounds-Klausel ¹⁾   ersetzt. Wenn es wie in unserem Fall keine Bounds-Klausel gibt, wird der Typparameter durch Object ersetzt.
• Zusätzlich werden wo nötig Casts und Brückenmethoden (bridge method) eingefügt.

Schauen wir uns ein Beispiel an, bei dem ein Cast eingefügt werden muss:

interface Bound1 { void f1(); }
interface Bound2 { void f2(); }

class MyGenericClass<T extends Bound1 & Bound2> {
  private T m1, m2;
  ...
  public void f() {
    m1.f1();
    m2.f2();
  }
}

class MyGenericClass {
  private Bound1 m1, m2;
  ...
  public void f() {
    m1.f1();
    ((Bound2)m2).f2();
  }
}

Was es mit den Brückenmethoden auf sich hat und wann sie benötigt werden, wollen wir hier nicht weiter diskutieren. Wer sich dafür interessiert, kann es in unserem Generics FAQ nachlesen (siehe /BRIDGE/).

Halten wir fest: ein generischer Typ entspricht im Byte-Code einem ganz normalen Referenztyp, bei dem der Typparameter durch seinen ersten Bounds-Typ oder - falls er keinen hat - durch Object ersetzt wird. Dieses Vorgehen nennt sich Type Erasure, da der Typparameter gelöscht wird und durch einen ganz normalen Referenztyp ersetzt wird. Da diese Transformation allein in einigen Situationen nicht ausreicht, werden wo nötig Casts und Brückenmethoden eingefügt. Das heißt, nach der Kompilierung ist ein generischer Typ ein ganz normales Interface oder eine ganz normale Klasse.

Damit das funktioniert, muss der Compiler auch an der Stelle eingreifen, an der der generische Typ als parametrisierter Typ genutzt wird. Dazu ein Beispiel in dem die LinkedList<A> aus unserem Beispiel oben genutzt wird. Hier der Code vor der Compilierung:

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);
  }
}

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);
  }
}

Fassen wir das bisher Gesagte noch mal zusammen: zur Laufzeit ist der generische Typ ein ganz normale Referenztyp, der fast ²⁾   nichts mehr von seiner Parametrisierung weiß. Dies gilt ganz besonders für ein Objekt eines parametrisierten Typs. Die LinkedList<String> weiß zur Laufzeit nicht, dass sie mit String parametrisiert wurde. Die Typprüfung auf Grund der Parametrisierung mit String erfolgt nur durch den Compiler zum Übersetzungszeitpunkt; zur Laufzeit ist keinerlei Typinformation über den Parametertyp mehr vorhanden.

²⁾   Das einschränkende ‚fast’ hat für die Diskussion über die Type Erasure keine Relevanz. Es gibt aber sehr wohl zur Laufzeit Unterschiede zwischen generischen Typen und normalen Referenztypen. Diese schauen wir uns im Detail im nächsten Artikel an.

When Worlds Collide

• alter Source Code, in dem ein generischer Tyl als Raw Type benutzt wird, und
• neuer Source Code, in dem eine Parametrisierung desselben generischen Typs vorkommt,

Schauen wir uns dazu ein Beispiel an:

class OldClass {
  ...
  public void foo(List l) {
    String s = (String) l.get(0);
    ...
  }

  public List bar() {
    List l = new ArrayList();
    // ... fill List l with Strings ...
    l.add("Hello World");
    return l;
  }
  ...
}

Jetzt wollen wir die beiden Methoden aus neu implementierendem Source Code, der parametrisierte Typen nutzt, aufrufen. Fangen wir mit foo() an:

OldClass oldClassObject = new OldClass();
List<String> l = new ArrayList<String>();
// ... fill List l with Strings ...
oldClassObject.foo(l);

Schauen wir nun, was beim Aufruf von bar() geschieht:

List<String> ll = oldClassObject.bar();  // unchecked warning
String s = ll.get(0);

Was wäre geschehen, wenn bar() Integers statt Strings in die Liste eingefügt hätte? Der Compiler hätte die Zuweisung einer solchen Raw-Type-Liste mit Integer-Elementen an die List<String> erlaubt – zwar mit Warnung, aber Warnungen kann man ja ignorieren. Dann hätte es beim Ablauf in der 2. Zeile eine ClassCastException gegeben:

List<String> ll = oldClassObject.bar();  // unchecked warning
String s = ll.get(0);                    // ClassCastException

List ll = oldClassObject.bar();  // unchecked warning
String s = (String) ll.get(0);   // ClassCastException

Mit ähnlichen Argumenten wie oben kann man sich überlegen, dass nicht nur der Aufruf von alten APIs aus neuem Code, sondern auch das Umgekehrte, nämlich der Aufruf von neuen APIs aus altem Code, funktioniert.

Zusammenfassend lässt sich sagen: wenn ein Objekt des Raw Types an eine Variable (oder einen Methodenparameter) von parametrisiertem Typ übergeben wird, dann meldet der Compiler eine unchecked warning.  Zur Laufzeit kann es später zu einer ClassCastException kommen, wenn das Raw-Type-Objekt Elemente eines anderen als des erwarteten Typs enthält. Dieses Problem bestand vor dem  JDK 5.0 schon in genau der gleichen Form.  Allerdings war die ClassCastException früher weniger überraschend als heute in Java 5.0, weil der Cast nach String im Source-Code deutlich sichtbar war, wohingegen nun in Java 5.0 eine ClassCastException an einer Stelle im Source-Code ausgelöst wird, an der weit und breit kein Cast zu sehen ist. Es ist der vom Compiler „heimlich“ eingefügte Cast, der scheitert – und das erschwert die Fehlersuche in solchen Situation. ³⁾

³⁾ Eine solche Situation, in der eine Variable von einem parametrisierten Typ auf ein Objekt von einem unpassenden Typ verweist, wird übrigens als Heap Pollution bezeichnet (Details siehe /POLL/).

Zusammenfassung

• 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 gleich 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.

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)