In der letzten Ausgabe dieser Kolumne haben wir das in Java 5.0 neue Sprachmittel der generischen Typen (Java Generics) in einem Überblick vorgestellt (siehe /KREFT/).  Heute wollen wir uns ein spezifisches Element der generischen Typen, die Wildcards, genauer ansehen.
 

Was sind Wildcards?

Das Schöne an einem parametrisierten Type wie List<String> ist, dass der Compiler den Elementtyp der Liste überprüfen kann. So achtet er darauf, dass mit der add() Methode nur Objekte vom Typ String in die Liste eingefügt werden. Deshalb entfällt auch der lästige explizite Downcast, wenn ein Element mit get() aus der Liste herausgeholt wird; die get() Methode von List<String> liefert immer ein Objekt von Typ String zurück.
 

List<String> myList = new ArrayList<String>();
myList.add(“Hello World”);
...
String tmpString = myList.get(0);  // kein Downcast nötig

Das einfachste Wildcard ist das unbeschränkte Wildcard, dargestellt durch das Fragezeichen "?". Es steht für "alle Referenztypen"; man kann es auch als: "irgendein beliebiger Referenztyp"  interpretieren.   Eine Variable von einem wildcard-parametrisierten Typ, wie z.B.

List<?> newList = null;

newList = new ArrayList<String>();
newList = new LinkedList<Integer>();
...

newList = new ArrayList<?>(); // falsch

Neben dem unbeschränkten Wildcard gibt es noch zwei weitere Wildcards. Das eine ist das nach oben beschränkten Wildcard:

? extends supertype

Schauen wir uns dazu ein Beispiel an: "? extends Runnable" bezeichnet

• einen beliebigen Typ, der von Runnable abgeleitet ist (also ein Sub-Interface von Runnable oder eine Klasse, die Runnable implementiert) oder
• Runnable selbst.

List<? extends Runnable> myList = null;

myList = new LinkedList<Runnable>();
myList = new ArrayList<Thread>();

Das dritte und letzte Wildcard ist das nach unten beschränkte:

? super subtype

Bisher wirken die drei Wildcards recht abstrakt und es ist ziemlich unklar, wie man sie in der Praxis einsetzten kann. Aber jeder der Typen liefert in bestimmten Situationen Lösungen bei der Benutzung generischer Typen in Java. Im folgenden wollen wir diese Situationen diskutieren.

Der unbeschränkte Wildcard Typ

void oldPrintCollection(Collection c) {
  Iterator i = c.iterator();
  for (int k = 0; k < c.size(); k++)
    System.out.println(i.next());
}

void newPrintCollection(Collection<Object> c) {
  for (Object e : c)
    System.out.println(e);
}

List<String> myStrings = new ArrayList<String>();
   . . . // fill the list with some strings
newPrintCollection(myStrings); // compile error: incompatible argument type

List<Object> myObjects = new ArrayList<Object>();
   . . . // fill the list with some strings
newPrintCollection(myObjects);

Das eigentliche Problem mit unserer newPrintCollection() Methode ist, dass wir gehofft hatten, durch die Definition des Methodenparameters als Collection<Object> würde auch Collection<String> akzeptiert. Das ist aber nicht so. Beide Typen stehen in keinerlei Beziehung zueinander.  Sie sind zwar durch Parameterisierung aus demselben generischen Typ entstanden, aber sie sind in keiner Weise  kompatibel zueinander.
 

Die Annahme einer Typkompatibilität stammt in Java daher, dass eine solche Typkompatibilität für Arrays existiert: überall, wo ein Object[] erwartet wird, kann man ein String[] übergeben.  Der Compiler überträgt die Super-Subtyp-Beziehung der Array-Elemente auf die Arrays selbst: da String ein Subtyp von Object ist, ist String[] auch ein Subtyp von Object[]. Was für Arrays gilt, könnte doch eigentlich auch für ArrayLists gelten, oder nicht?  Das ist aber nicht der Fall.  Für parametrisierte Typen überträgt sich aus gutem Grund die Super-Subtyp-Beziehung der Typargumente nicht auf die parametrisierten Typen, auch wenn das auf den ersten Blick intuitiv erscheinen mag. 1) Der Typ des Parameters von newPrintCollection() ist also das Problem in unserem Beispiel. Er darf nicht Collection<Object> sein, sondern muss so was wie "Collection von irgendeinem beliebigen Referenztyp" sein. Und genau das ist Collection<?>.   Die Definition unserer Methode sollte also besser so aussehen: void newPrintCollection(Collection<?> c) {    for (Object e : c)      System.out.println(e); } Damit lassen sich jetzt Collections beliebigen Elementtyps an die Methode übergeben.

1) Der Grund für die Inkompatibilität von List<Object> und List<String>, im Gegensatz zu Object[] und String[], liegt darin, dass eine solche Kompatibilität eine Typprüfung zur Laufzeit erfordern würde, die aber in Java gar nicht durchführbar ist.  Bei Arrays wird zur Laufzeit der sogenannte Array-Store-Check durchgeführt, der mit einer ArrayStoreException fehl schlägt, wenn entdeckt wird, dass ein falsches Element in das Array eingefügt wird.  Zum Beispiel: Object[] array = new String[2]; array[0] = new Date();  // ArrayStoreException Eine entsprechende Typprüfung wäre auch bei List<Object> und List<String> erforderlich, wenn sie kompatibel wären.  Diese Typprüfung ist aber wegen der Type Erasure, die wir in einem der Folgeartikel besprechen werden, in Java  gar nicht möglich.  Deshalb überträgt sich, anders als bei Arrays, die Super-Subtyp-Beziehung der Typargumente nicht auf die parametrisierten Typen.

Wenn man ehrlich ist, ist der Wildcard-Typ nicht die einzig mögliche Lösung für unser Problem. Die andere Lösung sieht so aus:

 <T> void newPrintCollection(Collection<T> c) {
  for (Object e : c)
    System.out.println(e);
}

List<String> myStrings = new ArrayList<String>();
   . . . // fill the list with some strings
newPrintCollection(myStrings);

Es gibt noch einen kleinen Unterschied zwischen den beiden Ansätzen (nicht-generische Methode mit Wildcard-Typ vs. generische Methode ohne Wildcards), der aber erst bei komplexeren Konstellationen zum Tragen kommt. Vergleichen wir dazu folgende zwei Methoden:

void print(Collection<Tuple<?>> tpls) {
  for (Tuple<?> t : tpls)
    System.out.println(t);
}

<T> void print(Collection<Tuple<T>> tpls) {
  for (Tuple<T> t : tpls)
    System.out.println(t);
}

Wir haben oben schon erwähnt, dass es für die Verwendung von wildcard-parametrisierten Typen gewisse Einschränkungen gibt.  Zum Beispiel kann man keine Objekte von wildcards-parametrisierten Typen erzeugen. Es gibt aber noch weitere Einschränkungen, die aber für die verschiedenen Arten von Wildcards jeweils anders sind. Für das unbeschränkte Wildcard gilt die Einschränkung, dass man keine Methode aufrufen darf, die den Typparameter als Methodenparameter haben. Das folgende ist also falsch und läßt sich nicht kompilieren:

List<?> l = new LinkedList<String>();
l.add("Hello World"); // falsch

void foo(List<?> l) {
   l.add("Hello World"); // falsch
}

Eine Ausnahme von der Regel gibt es natürlich doch noch. Das Folgende funktioniert:

void foo(List<?> l) {
   l.add(null); // richtig
}

Wie ist das nun, wenn der Typparameter nicht der Argumenttyp, sondern der Returntyp einer Methode ist? Gibt es da auch Einschränkungen? Ja, aber nur unwesentliche. Der Aufruf solcher Methoden ist erlaubt. Aber da der Elementtyp der Liste nicht bekannt ist, kann der Compiler nur sicherstellen, dass das Objekt, das von der Methode zurückgeliefert wird, vom Typ Object ist.  Spezifischer Typinformation über den Returnwert ist nicht vorhanden, d.h. man ist in einer Situation wie vor der Benutzung generischer Typen und muss einen expliziten Cast einfügen, um den Typ wiederherzustellen:

List<String> stringList = new LinkedList<String>();
stringList.add(“Hello World”);
List<?> l = stringList;
Object o = l.get(0);
String s = (String) l.get(0);

Der nach oben beschränkte Wildcard Typ

void oldDrawAll(Collection c) {
  Iterator i = c.iterator();
  for (int k = 0; k < c.size(); k++)
    ((Shape)i.next()).draw(); // Zeile 1
}

Jetzt geht es wieder darum, den Code von oldDrawAll() so zu ändern, dass die Features des JDK 5.0, speziell die Typsicherheit der generischen Typen, zum Einsatz kommen. Der erste Versuch ist:

void newDrawAll(Collection<Shape> shapes) {
  for (Shape s : shapes)
    s.draw();
}

void newDrawAll(Collection<?> shapes) {
  for (Shape s : shapes) // Zeile 2
    s.draw();
}

void newDrawAll(Collection<?> shapes) {
  for (Object s : shapes)
    ((Shape)s).draw();
}

Ganz offensichtlich kommen wir mit allen bisher bekannten Ansätzen nicht weiter. Wir müssen von dem Parameter für newDrawAll() verlangen, dass er eine Collection von Shape oder irgendeinem Subtyp von Shape ist.  Wie wir bereits oben gesehen haben, läßt sich dies mit dem nach oben durch Shape beschränkte Wildcard "? extends Shape" ausdrücken.  Die Implementierung von newDrawAll() sieht dann so aus:

void newDrawAll(Collection<? extends Shape> shapes) {
  for (Shape s : shapes)
    s.draw();
}

Zum einen gibt es wieder als Alternative zum Wildcard eine Lösung mit einer generischen Methode, die die gleiche Typsicherheit und Funktionalität zur Verfügung stellt wie die mit dem Wildcard-Parameter. Die generische Methode sieht so aus:

<T extends Shape> void newDrawAll(Collection<T> shapes) {
  for (T s : shapes)
    s.draw();
}

List<? extends Shape> myList = new ArrayList<Shape>();
myList.add(new Circle()); // falsch! Zeile 3
myList.add(null); // Zeile 4: wieder okay

Der nach unten beschränkte Wildcard Typ

T max(T t1, T t2, Comparator<T> cmp) {
  if ( cmp.compare(t1,t2) < 0 )
    return t2;
  else
    return t1;
}

max(new Date(), someOtherDate, ...); // Zeile 5

class UniversalComparator implements Comparator<Object> {
  public int compare(Object o1, Object o2) {
    return o1.toString().compareTo(o2.toString);
  }
}

Die bisherige Implementierung der generischen Methode max() ist nicht falsch. Sie ist aber auch nicht allgemein genug, um jeden sinnvoll möglichen Comparator zu akzeptieren. Was sind denn sinnvoll mögliche Comparatoren? In unserem Beispiel mit Date wären es Comparatoren, die entweder Objekte vom Typ Date oder Objekte vom Typ Object vergleichen können, also Comparator<Date> oder Comparator<Object>. Verallgemeinert heißt das: Comparatoren, die den betreffenden Typ oder einen seiner Supertypen vergleichen können.  Das läßt sich mit Hilfe eines nach unten beschränkten Wildcards ausdrücken.  Die korrigierte Lösung von max() müßte also folgendermaßen aussehen:

 T max(T t1, T t2, Comparator<? super T> cmp) {
  if ( cmp.compare(t1,t2) < 0 )
    return t2;
  else
    return t1;
}

class MyDateComperator implements Comperator<Date> {
   public int compare(Date d1, Date d2) {
      Comperator<Object> tmpComp = new UniversalComperator();
      return tmpComp.compare(d1, d2);
   }
}

Auch bei einem parametrisierten Typ mit einem nach unten beschränkten Wildcard gibt es Einschränkungen in der Benutzung. Diese Einschränkungen sind aber andere als die bei unbeschränkten und nach oben beschränkten Wildcards. Schauen wir uns dazu ein Beispiel an:

List<? super Integer> d = new LinkedList<Number>();

Number i = d.get(0);    // falsch! Zeile 6

Object o3 = d.get(0);   // Zeile 7

d.add(new Integer(5));  // Zeile 8

Number n = new Long(5);
d.add(n);               // falsch! Zeile 9

Zeile 8 ist richtig, denn einen Integer kann man problemlos ohne Verletzung der Typsicherheit in eine List<Integer>, List<Number>, List<Serializable>  oder List<Object> tun.  Für genau diese Supertypen von Integer steht ja "? super Integer".  Damit ist auch klar, warum Zeile 9 wieder falsch ist: einen Long kann man nicht in einer List<Integer> ablegen. Der Compiler weiß aufgrund der Typinformation List<? super Integer> nicht, was für eine Liste es nun wirklich ist.  Es könnte ja eine List<Integer> sein.  Die Tatsache, dass d in unserem Beispiel eine List<Number> referenziert, in der man sehr wohl einen Long ablegen kann, ist nicht relevant, da der Compiler für d.add(n) den statischen Typ von d berücksichtigt, und der ist nun mal List<? super Integer>.

Zusammenfassung

Wir haben in diesem Artikel bewusst die schwierigeren Aspekte wie Multilevel-Wildcards (Beispiel: Collection<? extends Pair<String,?>>) ausgeklammert. Wir haben auch nicht vor, sie in einem weiterführenden Artikel zu diskutieren. Wer sich dafür interessiert, findet Informationen zu dem Thema in unserem Generics-FAQ, siehe /MULTI/.

Das nächste Mal befassen wir uns statt dessen mit der Type Erasure; das ist die Technik, mit der generischer Java-Source-Code in Java-Byte-Code übersetzt wird.  Die Type Erasure hat vielfältige Auswirkungen und stellt wichtiges Hintergrundswissen für jeden Benutzer der Java Generics dar.

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)