Nachdem wir uns in den vorangegangenen Beiträgen dieser Kolumne verschiedene Aspekte der Java Generics ausführlich angesehen haben, wollen wir in diesem und dem nächsten Beitrag zwei Fallstudien betrachten, in denen Generics verwendet werden.  Die Beispiele illustrieren, wie man selbst generische Typen entwirft und implementiert und worauf man dabei achten muss.

Wir wollen eine einfache Abstraktion implementieren, die zwei Objekte unterschiedlichen Typs enthält.  Sie soll Pair heißen und  zwei Typparameter haben, die die Typen der beiden enthaltenen Objekte repräsentieren. Es soll später möglich sein, dem Typ eines Paars anzusehen, was es enthält, d.h. man möchte Typen wie Pair<String,String>, Pair<Date,Object>, usw. bilden.  Dazu muß die Klasse generisch sein.

Eine solche Pair-Abstraktion kann durchaus nützlich sein, beispielsweise als kombinierter Returnwert, wenn einer Methode zwei Objekte zurückliefern muss.  Da eine Funktion nur einen einzigen Returnwert liefern kann, muß sie die Rückgabeinformationen in einem einzigen Objekt zusammenfassen.  Sie könnte also ein Pair als Returnwert liefern.

Im Folgenden wollen wir schrittweise eine solche Pair-Abstraktion implementieren und daran demonstrieren, wie man Java Generics in der Praxis verwenden kann.
 

Generische vs. nicht-generische  Pair-Klasse

public final class Pair<X,Y> {
  private X first;
  private Y second;
  ...
}

Wie oben schon angedeutet, bietet eine generische Klasse die Möglichkeit, informativere Typen zu bilden, also zum Beispiel Pair<String,String> anstelle von Pair. Beim Typ Pair<String,String> sieht man gleich, daß Strings enthalten sind; beim Typ Pair ist aus dem Typ allein nicht sichtbar, was das Paar enthält.

Die generische Pair-Klasse ist aber auch semantisch anders als eine nicht-generische Pair-Klasse. Nicht nur, daß man einem  nicht-generischen Pair-Objekt nicht ansehen kann, was es enthält, es kann sogar in Verlauf seines Lebens gänzlich unterschiedliche Objekte enthalten: erst Äpfel und Birnen und später Double und Float.

Bei einer generischen Pair-Klasse ist das anders. Ein Pair<String,String> enthält zwei Strings; ein Pair<Number,CharSequence> enthält eine Zahl und einen Zeichenkette; ein Pair<Object,Object> kann alles enthalten, so wie es bei der nicht-generischen Pair-Klasse der Fall ist.  Prinzipiell liefert jedoch eine generische Pair-Klasse klarere Aussagen über die Art der enthaltenen Objekte und bringt auch deutlich zum Ausdruck, wenn man mit gemischten und wechselnden Typen von enthaltenen Objekten rechnen muß, wie im Falle eines Pair<Object,Object>. Dieser auf Grund der Verwendung von Generics deutlich deskriptivere Code hilft besonders, wenn es darum geht, Schnittstellen zwischen Programmteilen zu beschreiben. Auch die spätere Wartung des Programms wird erleichtert.

Da wir eine Pair-Klasse implementieren wollen, die möglichst aussagekräftige Typkonstrukte erlaubt, muss unsere Klasse also generisch sein.

Konstruktoren

public final class Pair<X,Y> {
  private X first;
  private Y second;
  ...
  public Pair() {
    first = null;
    second = null;
  }
  public Pair(X x, Y y) {
    first = x;
    second = y;
  }
  public Pair(Pair other) {
    if (other == null) {
      first  = null;
      second = null;
    } else {
      first  = other.first;    // error: incompatible types
      second = other.second;   // error: incompatible types
    }
  }
}

Der Fehler liegt in der Deklaration des Argumenttypen des Copy-Konstruktors.  Wir haben als Typ des Konstruktor-Arguments Pair deklariert (ohne Typargumente in spitzen Klammern); Pair ist der sogenannte Raw Type.  In dem Raw Type Pair sind die beiden enthaltenen Objekte vom Typ Object, weil für die Typparameter X und Y nichts spezifiziert wurde (siehe / GEN3 /).  Folglich sind die beiden Felder im Pair other vom Typ Object und damit inkompatibel zu den Feldern von this, die nämlich vom Typ X und Y sind.

Das ist ein typischer Fehler, den insbesondere Programmierer machen, denen Java Generics neu sind.  In der Regel geschieht es unabsichtlich.  Deshalb sollte man es sich zur Gewohnheit machen, generische Typen stets mit Typargumenten zu versehen.

Schauen wir uns an, wie wir unseren Fehler beheben können.  Wem nicht klar ist, daß die Fehlermeldung von der Raw Type Verwendung herrührt, der könnte auf folgende Lösung kommen:  man könnte den Compiler doch zum Schweigen bringen, indem ein Cast eingefügt wird.  Die beiden fraglichen Anweisungen könnten wie folgt "repariert" werden:

      first  = (X)other.first;      // warning: unchecked cast
      second = (Y)other.second;     // warning: unchecked cast

Jetzt ist zumindest der Fehler weg, aber wir bekommen statt dessen Warnungen.  Solche „unchecked cast“-Warnungen bekommt man immer, wenn der Zieltyp des Casts ein Typparameter ist.  Das liegt daran, daß Typparameter zur Laufzeit wegen der Type Erasure keine Typrepräsentation haben, so dass der Cast zur Laufzeit nicht so ausgeführt werden kann, wie es der Sourcecode glauben macht (siehe / GEN4 /).

Nun kann man Warnungen einfach ignorieren - immerhin läßt sich der Sourcecode ja übersetzen.  Was passiert, wenn wir die Warnungen ignorieren?  Möglicherweise gar nichts, wahrscheinlich ist aber eine unerwartete ClassCastException an einer Stelle, die keinerlei Hinweis auf die Ursache der Exception gibt.  Hier ist ein Beispiel für eine Situation, in der eine solche unerwartete ClassCastException ausgelöst wird:

public static void main(String... args) {
  Pair<String,Integer> p1
     = new Pair<String,Integer>("Bobby",10);
  Pair<String,Date> p2
     = new Pair<String,Date>(p1);
  ...
  Date bobbysBirthday = p2.getSecond();    // ClassCastException
}

Das macht u. U. lange keine Probleme, aber früher oder später wird man auf den zweiten Teil des Paares zugreifen, in der festen Überzeugung, daß es sich um ein Datum handelt.  Und genau in diesem Moment stellt sich heraus, daß das vermeintliche Datum ein Integer ist und es gibt eine ClassCastException.  Diese ClassCastException entsteht völlig unerwartet.  Man erwartet ClassCastExceptions eigentlich nur als Ergebnis eines gescheiterten Casts, aber in der betreffenden Sourcecodezeile ist weit und breit kein Cast zu sehen.   Die ClassCastException wird nämlich ausgelöst durch einen Cast, den der Compiler im Zuge der Type Erasure heimlich eingefügt hat; dieser Cast ist im Sourcecode nicht sichtbar.

Wer unchecked-Warnungen ignoriert, muß also mit unerwarteten ClassCastExceptions rechnen.  Das Unangenehme an diesen unerwarteten Exceptions ist, daß ihre Ursache in der Regel nur schwer zu identifizieren ist, weil sie in einem ganz anderen Teil der Applikation schlummert.  In unserem Beispiel liegt das Problem beim Copy-Konstruktor der Pair-Klasse: der Argumenttyp ist schlicht falsch deklariert und die unchecked-Casts verschleiern dieses Problem, statt es zu lösen.

Korrekt wäre folgende Lösung:  Wie oben schon angedeutet, müssen wir als Argumenttyp des Copy-Konstrutors statt des Raw Types eine konkrete Parametrisierung der Pair-Klasse deklarieren, um das Problem zu lösen.  In Frage käme die Parametrisierung Pair<X,Y>.  Das würde bedeuten, daß ein neues Paar nur als Kopie eines Paars des exakt gleichen Typs erzeugt werden kann.  Der Copy-Konstruktor sähe dann so aus:

public Pair(Pair<X,Y> other) {
  if (other == null) {
    first  = null;
    second = null;
  }
  else {
    first  = other.first;
    second = other.second;
  }
}

public static void main(String... args) {
  Pair<String,Integer> p1
   = new Pair<String,Integer>("planet earth",10000);
  Pair<String,Number> p2
   = new Pair<String,Number>(p1);   // error: no matching constructor
}

• man macht den Copy-.Konstruktor generisch oder
• man verwendet einen Wildcardtyp als Argumenttyp.

Generischer Konstruktor vs. Wildcard-Argumenttypen

public <A extends X, B extends Y>
Pair(Pair<A,B> other) {
  if (other == null) {
    first  = null;
    second = null;
  }
  else {
    first  = other.first;
    second = other.second;
  }
}

public static void main(String... args) {
  Pair<String,Integer> p1
     = new Pair<String,Integer>("Bobby",10);
  Pair<String,Date> p2
     = new Pair<String,Date>(p1);  // error
  Pair<String,Number> p3
   = new Pair<String,Number>(p1);  // fine
}

public Pair(Pair<? extends X,? extends Y>  other) {
  if (other == null) {
    first  = null;
    second = null;
  }
  else {
    first  = other.first;
    second = other.second;
  }
}

Wie das Beispiel des Copy-Konstruktors illustriert, ist die Verwendung von Wildcard-Typen oder generischen Methoden keineswegs exotisch, sondern selbst bei einfachen generischen Klassen bereits sehr naheliegend.
 

Value-Semantik

public Pair(Pair<? extends X,? extends Y>  other) {
  if (other == null) {
    first  = null;
    second = null;
  }
  else {
    first  = other.first.clone();   // error
    second = other.second.clone();  // error
  }
}

Es wäre naheliegend, nach Cloneable zu casten, um so die clone()-Methode im unbekannten Subtyp von X bzw. Y zugänglich zu machen.  Das sähe etwa so aus:

public Pair(Pair<? extends X,? extends Y>  other) {
  if (other == null) {
    first  = null;
    second = null;
  }
  else {
    first  = ((Cloneable)(other.first)).clone();   // error
    second = ((Cloneable)(other.second)).clone();  // error
  }
}

Die einzige Möglichkeit, die clone()-Methode aufzurufen, ist die Verwendung von Reflection.  Das sähe dann so aus:

public Pair(Pair<? extends X,? extends Y>  other) {
  if (other == null) {
    first  = null;
    second = null;
  }
  else {
    try {
      first  = (X)other.first.getClass()
               .getMethod("clone",null).invoke(other.first,null);  // unchecked warning
      second = (Y)other.second.getClass()
               .getMethod("clone",null).invoke(other.second,null); // unchecked warning
    } catch (Exception e) {
      first  = other.first;
      second = other.second;
    }
  }
}

Es gibt aber hier noch ein anderes Problem:  der Compiler liefert "unchecked"-Warnungen.  Das liegt daran, dass Methoden, die über Reflection aufgerufen werden, immer Object zurück liefern.  Genauer gesagt, um eine Methode über Reflection aufzurufen, wird die Methode invoke() der Klasse java.lang.reflect.Method benutzt.  Das sieht man im obigen Beispiel: getMethod() liefert das Method-Objekt für die clone()-Methode und anschließend wird die clone()-Methode per invoke() aufgerufen.  Die invoke()-Methode liefert den Returnwert der aufgerufenen clone()-Methode über eine Referenz vom Typ Object zurück.  Das ist immer so, wenn Methoden, die über Reflection aufgerufen werden, denn über die invoke()-Methode können beliebige Methoden mit beliebigen Returntypen aufgerufen werden.  Was auch immer der Returnwert ist, beim Aufruf über invoke() kommt er als Object-Referenz zurück.

Wir verlieren beim reflektiven Aufruf also Typinformation.  Selbst wenn in userem Beispiel die fraglichen clone()-Methode Objekte vom Typ X bzw. Y zurückgeben, bekommen wir immer nur eine Object-Referenz auf den Returnwert geliefert.  Es ist also ein Cast auf den eigentlichen Returntyp nötig, in unserem Fall ein Cast mit dem Zieltyp X bzw. Y.  Das Problem ist nun, dass X und Y die Typparameter der Pair-Klasse sind und zur Laufzeit keine Repräsentation haben wegen der Type Erasure.  Solche Casts können zu Problemen führen, wie wir oben (in Abschnitt "Konstruktoren") bereits diskutiert haben.  Der Compiler gibt also aus gutem Grund eine Warnung ab.

Normalerweise kann man "unchecked"-Warnungen durch typkorrektes Programmieren vermeiden; auch das haben wir oben schon gesehen.  Hier gibt es aber keine Möglichkeit, den Cast zu vermeiden.  Man kann bestenfalls mit einer @SuppressWarning("unchecked")-Annotation die Warnungen unterdrücken.  Ehe man das tut, sollte man sich aber fragen, ob man die Warnung wirklich getrost ignorieren kann.  Kann hier irgendwas schief gehen?

Zur Laufzeit werden die Casts nach X bzw. Y durch Casts nach Object, also durch "gar nichts" ersetzt.  Es wird also nicht geprüft, ob das Ergebnis des Klonens vom erwarteten Typ X bzw. Y ist.  Das muss aber auch gar nicht geprüft werden.  Wenn die clone()-Methoden von other.first und other.second korrekt implementiert sind, dann liefern sie Objekte vom Typ X bzw. Y zurück.  Der Cast ist hier nur erforderlich, weil die clone()-Methoden über Reflection aufgerufen werden müssen und dabei geht unvermeidlich die Information über den Returntyp verloren.   Das heißt aber nicht, dass die clone()-Methoden nun plötzlich unerwartete Typen von Objekten zurückliefern.  Es besteht also keine Gefahr und die "unchecked"-Warnungen können guten Gewissens unterdrückt werden.

Was wir hier am Beispiel des Copy-Konstruktors beschrieben haben, zieht sich natürlich durch die gesamte Implementierung der Pair-Klasse.  Auch andere Konstruktoren und Methoden werden Klone erzeugen und dabei Reflection verwenden und Warnungen unterdrücken müssen.
 

Zusammenfassung

Wir haben gesehen, was passiert, wenn man unchecked-Warnungen ignoriert.  Wir haben festgestellt, daß generische Methoden und Wildcard-Typen selbst in einfachen generischen Klassen bereits vorkommen.  Wir sind auf das uralte Problem mit dem leeren Cloneable-Interface gestoßen.  Und wir haben erlebt, daß man "unchecked"-Warnung manchmal gar nicht vermeiden kann.
 
 
 

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   Java 5.0 Language Features - An overview of all language features added to Java in release 5.0; includes generics, concurrency utilities, enumeration types, auto-boxing, etc. 2 day seminar (on-site) Java Generics - Java Generics Explained: Everything You Always Wanted To Know About Generics 2 day seminar ( open enrollment and on-site) Effective Java - Java best practice programming techniques, common pitfalls, and off-the-beaten-path language features 4 day seminar ( open enrollment and on-site)