In der letzten Ausgabe dieser Kolumne haben wir uns angesehen, welche Überraschungen sich bei der Benutzung von generischen Typen durch die Type Erasure Technik ergeben können. Diesmal wollen wir uns ein Problem ansehen, dass sich häufig ergibt, wenn man eigene generische Typen bzw. Methoden implementieren möchte. Auch dieses Problem wird durch die Type Erasure verursacht.  Es geht um das Erzeugen von Objekten und Arrays, in deren Typ ein Typparameter vorkommt, also um Objekte vom Typ T und Arrays vom Typ T[], wobei T ein Typparameter ist.
 

Wiederholung Type Erasure

• Aus einem generischen Typ (z.B. interface Callable<V>) wird ein nicht-generischer Typ, indem die Typparameter entfernt und durch den ersten Typ in ihrer Bounds-Klausel ersetzt werden. Wenn es keine Bounds-Klausel gibt, wird der Typparameter durch Object ersetzt.
• Aus einem parametrisierten Typ (z.B. Callable<Long>) wird ein regulärer Typ, indem die Typargumente entfernt werden.

Das Problem

class Utilities {
  private static final int SIZE = 1024;
  public static <T> T[] createBuffer() {
    return new T[SIZE] ; // Fehler beim Kompilieren
  }
}
public static void main(String[] args) {
  String[] buffer = Utilities. <String> createBuffer();
}

public static <T> T createObject() {
  return new T(); // Fehler beim Kompilieren
}

Wenn man createObject() übersetzen könnte, so entspräche der erzeugte Bytecode in etwa dem folgenden Javacode:

public static Object createObject() {
  return new Object();
}

Ein weiterer Grund für die Weigerung des Compilers, Objekte oder Arrays von unbekanntem Typ zu erzeugen, liegt darin, dass Ausdrücke wie new T oder new T[SIZE] unterstellen, dass der unbekannte Typ T eine Klasse mit einem Default-Konstruktor ohne Argumente ist.  Das ist aber keineswegs gewiß; für den Typparameter T könnte später ein Interface-Typ eingesetzt werden oder eine Klasse, die keinen Default-Konstruktor hat.  Der Compiler weiss also gar nicht, ob new T oder new T[SIZE] korrekte Ausdrücke sind und weist diese Konstrukte deshalb mit einer Fehlermeldung ab.

Verschiedene Lösungen

Das Beispiel, das wir dazu diskutieren wollen, ist folgendes:

public class CyclicBuffer<T> {
  private T[] myBuffer = new T[1024]; // Fehler beim Compilieren
   ...

  public void put(T t) { ... }
  public T get() { ... }

}

Die Funktionalität von CyclicBuffer wird durch zwei Methoden bereitgestellt:

• put() tut ein Objekt vom Typ T in den Ringpuffer und
• get() holt eines heraus.

1. Lösungsansatz: ArrayList<T> statt T[]

public class CyclicBuffer<T> {
  private ArrayList<T> myBuffer = new ArrayList<T>(1024);
   ...
}

2. Lösungsansatz: Expliziter Parameter (Objekt)

public class CyclicBuffer<T> {
  private T[] myBuffer;
  private int length;
   ...

  public CyclicBuffer (T[] buf) {
    myBuffer = buf;
    length = buf.length;
  }
   ...
}

Dieser Lösungsansatz wird sich auch nicht immer verallgemeinern lassen. So mag es zum Beispiel unintuitiv sein, wenn eine Methode, die ein temporäres Ergebnis erzeugt und im Returnwert zurückgibt, das eigentliche Rückgabeobjekt als Parameter übergeben bekommt. Aber auch dafür gibt es Beispiele im JDK, wie wir weiter unten sehen werden.

Einen entscheidenden Vorteil hat diese Lösung aber gegenüber der ersten: sie kann auch angewandt werden, wenn ein Objekt und kein Array vom Typ des Typparameters erzeugt werden soll.

3. Lösungsansatz: Expliziter Parameter (Klasse)

Übertragen auf unser Beispiel sieht dieser Lösungsansatz dann so aus:

public class CyclicBuffer<T> {
  private T[] myBuffer;
   ...

  public CyclicBuffer (Class<T> bufType) {
    myBuffer = (T[]) Array.newInstance(bufType, 1024);
  }
   ...
}

CyclicBuffer<String> myCb = new CyclicBuffer<String>(java.lang.String.class);

CyclicBuffer<String> myCb = new CyclicBuffer<String>(java.lang.Integer.class);

Das übergebene Class-Objekt bezeichnet man übrigens als Type Tag.

Anmerkungen

Wenn man sich den CyclicBuffer<T> noch einmal genauer ansieht, kann man feststellen, dass man nicht unbedingt einen Puffer vom Typ T[] braucht. Mit der entsprechenden Implementierung von get() und put() funktioniert das Ganze auch mit einem Buffer vom Typ Object[]:

public class CyclicBuffer<T> {
  private Object[] myBuffer = new Object[1024];
  private int readPtr;
  private int writePtr;

  public void put(T t) {
     ...
    myBuffer[writePtr] = t ;
     ...
  }

  public T get() {
     ...
    return ((T) myBuffer[readPtr]); // Zeile 14
  }

}

Damit ist die Verwendung eines Object[] anstelle eines T[] ein weiterer Lösungsansatz für unser Beispiel, der aber leider nicht so universell anwendbar ist. Deshalb haben wir ihn auch nicht oben schon diskutiert. Wie schnell diese Lösung an ihre Grenzen stößt, kann man sehen, wenn CyclicBuffer<T> eine Methode dumpBuffer() erhalten soll, bei der man den internen Puffer als T[] zurück gibt:

public class CyclicBuffer<T> {
  private Object[] myBuffer = new Object[1024];

  public void put(T t) { ... }
  public T get() { ... }
  public T[] dumpBuffer { return myBuffer; } // Compiler Fehler: Type mismatch ...
}

Und im JDK ?

Die Methode java.util.AbstractCollection<E>.toArray() aus dem JDK ist ein gutes Beispiel für die Kombination der diskutierten Lösungsansätze. Die Methode gibt es in zwei überladenen Varianten, die an alle Collections (aus dem mit JDK 1.2 eingeführten Collection Framework) weitervererbt werden:

public abstract class AbstractCollection<E> implements Collection<E> {
   …
  public Object[] toArray() { … }
  public <T> T[] toArray(T[] a) { … }
}

LinkedList<Integer> lli = new LinkedList<Integer>();
// … lli füllen
Integer[] ia = lli.toArray(new Integer[0]);         // Zeile 3
Number[]  na = lli.toArray(new Number[lli.size()]); // Zeile 4
Object[] oa1 = lli.toArray(new Object[1]);          // Zeile 5
Object[] oa2 = lli.toArray();                       // Zeile 6

Wie man sehen kann, basiert die Lösung hier auf einer Kombination des Lösungsansatzes 2 mit einer Variante des Lösungsansatzes 3. Wenn das als Parameter übergebene Array groß genug ist, wird der Inhalt der Collection in das Array kopiert und dieses wieder zurückgegeben (Lösungsansatz 2). Wenn das als Parameter übergebene Array nicht groß genug ist, wird über Reflection ein neues konstruiert, wobei der Elementtyp derselbe ist, wie der des übergebenen Arrays. Dies ist eine Variante des Lösungsansatzes 3, denn der Typ des Arrays wird nicht direkt als Parameter übergeben, sondern erst an Hand des übergebenen Array-Objekts ermittelt.

Dieses Bespiel aus dem JDK zeigt sehr schön, wie die oben diskutierten Lösungsansätze in der Praxis verschmelzen können.

Zusammenfassung

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)