Die Version 7 von Java hat eine Reihe von kleineren Sprachergänzungen gebracht, die unter dem Namen "Project Coin" entwickelt wurden.  Wir haben im vorangegangenen Beitrag unserer Reihe über Java7-Neuerungen einen Teil dieser Neuerungen angesehen.  Dieses Mal wollen wir die neuen Sprachmittel vorstellen, die Verbesserungen im Zusammenhang mit Generics betreffen.
 

Sprachverbesserungen im Zusammenhang mit Generics

(a) eine verbesserte Type Inference für Konstruktoren generischer Typen und um
(b) Probleme im Zusammenspiel von variablen Argumentenlisten und nicht-reifizierbaren Typen.

Der Diamond -Operator

Beispiel (kompletter Typename):

ThreadLocal<Map<String, List<Integer>>> ref = new ThreadLocal<Map<String, List<Integer>>>();

Sollte man aus Bequemlichkeit oder Unachtsamkeit die Schreibweise vereinfacht haben, bekommt man vom Compiler allerlei Warnungen.

Beispiel (Raw Type):

ThreadLocal<Map<String, List<Integer>>> ref = new ThreadLocal();

In Java 7 gibt es nun den sogenannten Diamond -Operator, der die Schreibweise vereinfacht und den Compiler veranlasst, sich die fehlende Information selber aus dem Kontext des Konstruktoraufrufs zu überlegen.

Beispiel ( Diamond -Operator):

ThreadLocal<Map<String, List<Integer>>> ref = new ThreadLocal<>();

Das leere Klammer-Paar wird als Diamond Operator bezeichnet, obwohl er kein Operator im eigentlichen Sinne der Sprache ist, sondern nur ein syntaktisches Konstrukt, das den Raw Type vom parametrisierten Typ ohne Typparameter unterscheidet.

Die Deduktion der fehlenden Typparameter aus dem Kontext nennt man Type Inference .  Type Inference gibt es schon, seit es die Java Generics gibt; sie wird auch im Zusammenhang mit dem Aufruf generischer Methoden verwendet.   Die Type Inference ist nun für Java 7 auf Konstruktoraufrufe ausgedehnt worden (siehe /JSR334/ und /DIAMND/).

Wie so häufig im Zusammenhang mit Generics ist nicht alles so einfach, wie man es sich wünschen würde.  Die Type Inference führt nämlich gelegentlich zu überraschenden Ergebnissen.

Beispiel ("interessante" Type Inference):

Set<Number> s3 = new HashSet<>(Arrays.asList(0L,0L)); // error

Welche Strategie wählt nun der Compiler?

Das ist klar geregelt: Für den Compiler haben die Konstruktorargumente Vorrang; er deduziert also E:=Long und dann gibt es eine Fehlermeldung, weil der Set<Number> auf der linken Seite inkompatibel zum HashSet<Long> auf rechten Seite ist.

Das ist vielleicht nicht ganz die Deduktion, die man sich gewünscht hätte, aber es ist eine definierte und auch sinnvolle Deduktionsstrategie.  Die Strategie bei der Type Inference ist nämlich für generische Methoden und den Diamond -Operator identisch:  Der Compiler schaut sich immer erst die Typen der Konstruktor- bzw. Methodenargumente an. Nur wenn er daraus nichts deduzieren kann, schaut er die linke Seite der Zuweisung an.  Letzteres tut er natürlich nur, wenn der Konstruktor- bzw. Methodenaufruf im Kontext einer Zuweisung steht.

Und was ist, wenn der Diamond -Operator nicht im Kontext einer Zuweisung auftaucht? Das wollen wir jetzt an dieser Stelle nicht vertiefen.  Aber auch dafür gibt es Regeln.  Wer sich für die Details der Type Inference interessiert, kann sie in den Generics FAQs (siehe /GENFAQ1/) nachlesen.

Insgesamt führt der Diamond -Operator zu spürbar weniger Code. Gelegentlichen gibt es Überraschungseffekten, wie oben erläutert.

Neben dem Code-Overhead bei Konstruktoraufrufen von generischen Typen hat man in Java 7 versucht, auch die Probleme zu beheben, die sich aus der Kombination von Varargs und Generics ergeben. Beide Sprachmittel, die variable Argumentenliste und die generischen Typen, sind mit Java 5 zur Sprache hinzugekommen. Augenscheinlich hat man die Kombination der beiden neuen Sprachmittel nicht bis in Detail durchdacht, denn bei gewissen Funktionsaufrufen gibt es Probleme.

Varargs und Generics

public static <T> List<T> asList(T... a);

Wenn die Aufrufargumente einer Methode mit einer variablen Argumentenliste von einem nicht-reifizierbaren Typ (siehe /GENFAQ2/) sind, dann produziert der Compiler eine unchecked-Warnung.

Nicht-reifizierbare Typen sind Typen, die aufgrund der Type Erasure im Byte-Code keine exakte Darstellung mehr haben.  Zu den nicht-reifizierbaren Typen gehören praktisch alle parametrisierten Typen (wie List<String> , Map<? extends Number,String> , Future<Long> , usw.) sowie alle Typvariablen (wie etwa T im obigen Beispiel).

Schauen wir uns ein Beispiel für die problematische Kombination von Varargs und Generics an:

List<ThreadLocal<String>> list2 = Arrays.asList(new ThreadLocal<String>());
____________________________________________________________________________________
warning: [unchecked] unchecked generic array creation for varargs parameter of type ThreadLocal<String>[]
List< ThreadLocal<String>> list2 = Arrays.asList(new ThreadLocal<String>());
                                                ^

Oft ist die Warnung des Compilers unberechtigt, weil die aufgerufene Methode so implementiert ist, dass sie mit dem compiler-generierten Array nichts Problematisches tut.  Ausgegeben wird die Warnung aber immer.  Dummerweise kann nun ausgerechnet der Aufrufer einer Varargs-Methode am allerwenigsten beurteilen, ob die Warnung berechtigt ist oder nicht;  das kann eigentlich nur der Implementierer der Methode beurteilen.

Die Änderung in Java 7 besteht nun darin, dass der Compiler die Warnung nicht mehr nur beim Aufruf der Varargs-Methode gibt, sondern auch schon bei der Definition der Methode (siehe /JSR334/ und /VARARG/).

Hier ist ein Beispiel:

public  static <E> void addAll(List<E> list, E... array) {
   for (E element : array) list.add(element);
}
public static void main(String[] args) {
   addAll(new ArrayList<Pair<String,String>>(),
      new Pair<String,String>("Leonardo","da Vinci"),
      new Pair<String,String>("Vasco","de Gama")
   );
}
______________________________________________________________________________

warning: [unchecked] Possible heap pollution from parameterized vararg type E
        public  static <E> void addAll(List<E> list, E... array) {
                                               ^
  where E is a type-variable:
    E extends Object declared in method <E>addAll(List<E>,E...)

warning: [unchecked] unchecked generic array creation for varargs parameter of type Pair<String,String>[]
            addAll(new ArrayList<Pair<String,String>>(),   // unchecked warning
                  ^

Nun sollte der Implementierer die Annotation @SafeVarargs natürlich nur dann benutzen, wenn er sicher weiß, dass auch wirklich keine Typprobleme auftreten können.  Wann ist eine vom Compiler monierte Varargs-Methode problematisch bzw. unproblematisch?  Das ist nicht immer ganz einfach zu beurteilen.

Hier ist ein offensichtliches Beispiel:

Pair<String,String>[] method ( Pair<String,String>... lists) {  //1: Warnung: possible heap pollution
   Object[] objs = lists;
   objs[0] = new Pair<String,String>("x","y");
   objs[1] = new Pair<Long,Long>(0L,0L);                      //2: heap pollution
   return lists;
}

public static void main(String[] args) {
   Pair<String,String>[] result
     = method ( new Pair<String,String>("Vasco","da Gama"),      //3: Warnung: generic array creation
           new Pair<String,String>("Leonard","da Vinci" ));
   for (Pair<String,String> p : result) {
     String s = p.getFirst();                                 //4: ClassCastException
   }
}

Wie ist es hier?  Ein weniger offensichtliches Beispiel:

<T> T[] method_2 ( T... args) {                       //1: Warnung: possible heap pollution
    return args;
}

<T> T[] method_1(T t1, T t2) {
    return method _2( t1, t2 );                        //2: Warnung: generic array creation
}

String[] strings = method_1("bad", "karma");        //3: ClassCastException

Object[] method_2( Object[] args) {                          //1: Warnung: possible heap pollution
   return args;
}
Object[] method_1(Object  t1, Object t2) {
   return method_2(new Object[] {t1, t2});                  //2: Warnung: generic array creation
}

String[] strings = ( String[] ) method_1("bad", "karma");     //3: ClassCastException

Fazit: Auch hier wäre die Verwendung einer @SafeVarargs -Annotation an der Varargs-Methode method_2() gänzlich unangebracht.  Leider ist es in diesem Falle aber überhaupt nicht offensichtlich.

Was also nützt die Neuerung in Java 7 im Zusammenhang mit Varargs und Generics?  Wenn der Implementierer einer Methode mit einer variablen Argumentenliste absolut sicher ist, dass seine Methode keine Heap Pollution verursachen kann, dann kann er mit der @SafeVarargs -Annotation dafür sorgen, dass der Aufrufer seiner Methode nicht mehr wie bisher mit unchecked-Warnungen belästigt wird, die er ohnehin nicht beurteilen kann.  Ob der Implementierer einer Varargs-Methode jedoch stets in der Lage ist, zuverlässig zu beurteilen, wann er die Annotation zu Recht verwendet und wann er einfach nur irrtümlich eine durchaus berechtigte Warnung unterdrückt, ist eine ganz andere Frage.  An dem zugrundeliegenden Problem, dass nämlich variable Argumentenlisten zur Erzeugung problematischer Array mit nicht-reifizierbarem Elementtyp führen, hat sich auch in Java 7 nichts geändert.
 

Zusammenfassung und Ausblick

Literaturverweise

Die gesamte Serie über Java 7:

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

Seminar   Effective Java - Advanced Java Programming Idioms  4 day seminar ( open enrollment and on-site)