6.12 Generische Datentypen 
Nehmen wir an, wir wollten einen Container für eine einfache Zahl implementieren; der Datentyp soll int sein:
class IntBox
{
private int val;
void setValue( int val )
{
this.val = val;
}
int getValue()
{
return val;
}
}Es gibt einen automatischen Standard-Konstruktor, und mit setValue() können wir eine Zahl angeben und den Wert über die Zugriffsfunktion auslesen. Was ist, wenn wir eine zweite Box für Strings implementieren wollen? Wir müssten Quellcode duplizieren und überall, wo int steht, den Datentyp String einsetzen:
class StringBox
{
private String val;
void setValue( String val )
{
this.val = val;
}
String getValue()
{
return val;
}
}In unserem Beispiel sind das drei Änderungen, aber der Rest des Gerüstes bleibt gleich. Für jeden neuen Datentyp muss eine neue Klasse her – die Logik bleibt die gleiche. Es gibt eine ganze Reihe von Beispielen, in denen Speicherstrukturen wie unsere Box nicht nur für einen Datentyp sinnvoll sind. Das gilt auch für Algorithmen, etwa einen, der Zahlen sortiert. Wenn zwei Zahlen größer oder kleiner sein können, muss ein Algorithmus lediglich diese Eigenschaft nutzen können, aber es wäre egal, ob die Zahlen von der Größe byte, short, int, long oder auch Gleitkommazahlen sind – der Algorithmus selbst ist davon nicht betroffen.
Ein Algorithmus, der von einem Datentyp unabhängig programmiert werden kann, heißt generisch, und die Möglichkeit, in Java mit generischen Typen zu arbeiten, heißt Generics. [In C(++) werden diese Typen von Klassen parametrisierte Klassen oder Templates (Schablonen) genannt. ] Leider funktioniert das Beispiel mit der IntBox in Java nicht, denn generische Typen können in Java nur Objekte sein, aber keine primitiven Datentypen. Das schränkt die Möglichkeiten zwar ein, doch weil es Autoboxing gibt, lässt sich damit leben.
Die Implementierung der Java-Generics basiert auf einem Projekt namens Pizza. Später wurde aus Pizza GJ, und schließlich wurde dies zur Basis des Java Specification Request 14: »Add Generic Types To The Java Programming Language«.
6.12.1 Einfache Klassenschablonen 
Wenn wir die StringBox als Basis nehmen, haben wir bei der Übersetzung der IntBox in die StringBox drei Stellen gefunden, an denen wir den Typ ändern müssen. Wollen wir die Box in einen generischen Typ umbauen, so müssen wir an den drei Stellen, an denen der konkrete Typ String vorkam, einen Typ-Stellvertreter, eine so genannte Typ-Variable, einsetzen. Der Name der Typ-Variable muss in der Klassendeklaration angegeben werden, da es durchaus mehr als einen Stellvertreter geben kann. Die Syntax für die generische Typdefinition für unsere Box ist folgende:
Listing 6.101 com/tutego/insel/generics/Box.java
package com.tutego.insel.generics; class Box<T> { private T val; void setValue( T val ) { this.val = val; } T getValue() { return val; } }
An Stelle des konkreten Typs String steht ein formaler Typ-Parameter, in unserem Fall ist das T – die Abkürzung ist oft T, das für Typ steht. Bei generischen Klassen steht die Angabe des Typnamens nur einmal zu Beginn der Klassendeklaration in spitzen Klammern hinter dem Klassennamen.
Um die Box nutzen zu können, müssen wir sie mit einem speziellen Typ erzeugen, dem parametrisierten Typ. Er ist eine Instanziierung eines generischen Typs mit konkreten Typargumenten (etwa String oder Integer oder Point). Der konkrete Typ steht hinter dem Klassennamen in spitzen Klammern.
Listing 6.102 com/tutego/insel/generics/GenericBoxExample1.java, Ausschnitt
Box<String> stringBox = new Box<String>(); Box<Integer> intBox = new Box<Integer>(); Box<Point> pointBox = new Box<Point>();
Das Schöne daran ist, dass nun alle generischen Eigenschaften mit dem angegebenen Typ durchgeführt werden. Wenn wir etwa aus pointBox mit getValue() auf das Element zugreifen, ist es vom Typ Point:
pointBox.setValue( new Point(1, 2) ); double x = pointBox.getValue().getX();
6.12.2 Einfache Methodenschablonen
Eine Klasse kann ganz normal ohne Generics deklariert werden, aber mit Methoden, die die Typen generisch vorschreiben. Das gilt für Objektmethoden und Klassenmethoden. Interessant ist dies für Utility-Klassen, die nur statische Funktionen anbieten, aber selbst nicht als Objekt vorliegen.
class Util
{
public static <T> T random( T m, T n )
{
return Math.random() > 0.5 ? m : n;
}
}Hier wird die Funktion random() auf einem beliebigen Typ deklariert; die Angabe von <T> beim Klassennamen entfällt und verschiebt sich auf die Deklaration der Methode.
Die Benutzung kann ohne Angabe des Typs – aber doch überprüft – geschehen:
String s = Util.random( "Essen", "Schlafen" );
Ersetzen wir einen der beiden Strings durch einen Wert vom Typ Integer, so wird der Compiler einen Fehler melden, da die beiden übergebenen Typen nicht übereinstimmen.
6.12.3 Umsetzen der Generics, Typlöschung und Raw-Types
Es gibt zwei Realisierungsmöglichkeiten von generischen Datentypen:
- Heterogene Variante. Für jeden Typ (etwa String, Integer, Point) wird individueller Code erzeugt, also drei Klassen.
- Homogene Übersetzung. Für jede parametrisierte Klasse wird eine Klasse erzeugt, die anstelle des generischen Typs Object einsetzt. Für einen konkreten Typ werden Typanpassungen in die Anweisungen eingebaut.
Java nutzt die homogene Übersetzung.
Typlöschung
Übersetzt der Java-Compiler die generischen Anwendungen, so löscht er dabei alle Typinformationen (engl. typ erasure). Das ist zwar für die Laufzeitumgebung praktisch, weil sie nicht auf die Generics großartig angepasst werden muss, sonst aber stellt das ein riesiges Problem dar, weil dann die Typinformationen zur Laufzeit nicht vorhanden sind. Programmierer müssen das wissen, da zum Beispiel der instanceof-Operator so nicht funktioniert:
Listing 6.103 com/tutego/insel/generics/GenericBoxExample2.java, Ausschnitt
Box<String> stringBox = new Box<String>(); boolean b1 = stringBox instanceof Box<Number>; // illegal generic type for instanceof boolean b2 = stringBox instanceof Box<String>; // illegal generic type for instanceof
Der Compiler meldet zu Recht einen Fehler – nicht nur eine Warnung –, weil es den Typ Box<String> und Box<Number> zur Laufzeit gar nicht gibt: Es sind nur typgelöschte Box-Objekte. Das zeigt auch das folgende Beispiel:
Listing 6.104 com/tutego/insel/generics/GenericBoxExample2.java, Ausschnitt
Box<String> box1 = new Box<String>(); Box<Integer> box2 = new Box<Integer>(); System.out.println( box1.getClass() == box2.getClass() ); // true
Dass diese Informationen übrigens nicht vorliegen, wird auch damit begründet, dass die Laufzeit leiden könnte. Microsoft war das aber egal, dort besteht Generizität in der Common Language Runtime (CLR). Microsoft ist damit einen klaren Schritt voraus.
Typanpassungen
Ein mit Generics spezifizierter Typ lässt sich durch Typanpassung auf eine allgemeine Form bringen:
List<Integer> list = new ArrayList<Integer>(); List noGenericList = (List) list;
Bei der noGenericList prüft der Compiler natürlich gar keine Typen mehr, denn er hat sie ja »vergessen«. Eine Anweisung, die einen Nicht-Integer-Typ in die Liste einfügt, bringt keinen Fehler zur Übersetzungszeit, und so kann über die Hintertür ein falscher Typ in die Datenstruktur kommen:
noGenericList.add( "Das macht man aber nicht" );
Die Generics bieten uns Möglichkeiten, den Quellcode sicherer zu machen. Wir sollten diese Sicherheit nicht durch ungetypte Schreibweisen kaputtmachen.
Raw-Type
Generische Klassen müssen nicht unbedingt parametrisiert werden; sie sind mit dem Datentyp Object weiterhin gültig. Das ist auch wichtig, da sonst viele parametrisierte neue Klassen nicht mehr mit altem Programmcode verwendet werden könnten.
Listing 6.105 com/tutego/insel/generics/GenericBoxExample3.java, Ausschnitt
Box stringBox = new Box<String>(); Box pointBox = new Box<Point>(); Box objectBox = new Box();
Ein generischer Typ ohne Typargument heißt Raw-Type. In unserem Beispiel ist Box der Raw-Type von Box<T>. Ein Raw-Type besitzt die gleichen Eigenschaften wie ein generischer Typ, nur kann der Compiler ohne parametrisierten Typ die Typkonformität nicht mehr prüfen. Im ersten Fall liefert getValue() den korrekten Typ String, Analoges gilt für Point. Im letzten Fall liefert getValue() nur Object, da hier jeder Bezug zum Typ fehlt.
Doch was ist eigentlich mit setValue()? Erinnern wir uns an die Deklaration:
void setValue( T val )
{
this.val = val;
}Diese Funktion ist so ausgelegt, dass sie ein Argument von mindestens dem Typ akzeptiert, mit dem sie parametrisiert wurde. Fehlt durch die Verwendung des Raw-Typs der konkrete Typ, bleibt Object, und der Compiler gibt eine Warnung aus:
objectBox.setValue( "Unsafe type operation: " +
"Should not invoke the method setValue(T) of raw type Box. " +
"References to generic type Box<T> should be parameterized" );Der Hinweis besagt, dass die Box typisiert hätte werden müssen. Achten wir darauf nicht, kann das schnell zu Problemen führen:
Box<String> stringBox2 = new Box<String>(); Box objectBox2 = stringBox2;
Der Compiler gibt keinen Fehler und auch keine Warnung aus. Die zweite Zeile ist allerdings hochgradig problematisch, denn über die nicht parametrisierte Objekt-Box können wir beliebige Objekte in die Box packen. Da aber objectBox2 in Wirklichkeit ein typgelöschter Verweis auf die stringBox2 ist, haben wir ein Typproblem:
objectBox2.setValue( new java.util.Date() ); // Warnung vor der "Unsafe type operation" String s = stringBox2.getValue(); System.out.println( stringBox2.getValue() );
Die letzten beiden Zeilen führen zur Laufzeit zu einer ClassCastException der Art:
Exception in thread "main" java.lang.ClassCastException: java.util.Date at com.tutego.insel.generics.GenericBoxExample3.main(GenericBoxExample3.java:17)
6.12.4 Einschränken der Typen
Bei generischen Angaben können die Typen weiter eingeschränkt werden. Es kann vorgeschrieben werden, dass der Typ eine konkrete Schnittstelle implementieren muss. Unsere Deklaration von random() sah keine Einschränkungen vor, sodass zum Beispiel auch Folgendes möglich ist:
Serializable s1 = new Serializable() { };
Serializable s2 = new Point();
Util.random( s1, s2 );Da der Typ beliebig ist, können auch Objekte aufgenommen werden, die vielleicht wenig Sinn ergeben, wie unsere Klassen, die lediglich Serializable implementieren.
Einschränkung mit extends
Um dies zu vermeiden, kann der Typ bei der Deklaration eingeschränkt werden. Wollen wir nur Klassen, die CharSequence implementieren (also Zeichenfolgen wie String und StringBuffer/StringBuilder), so schreiben wir das in die Deklaration mit hinein:
public static <T extends CharSequence> T random( T m, T n ) { return Math.random() > 0.5 ? m : n; }
Jetzt wird der Compiler mit übergebenem Serializable einen Fehler melden. Einen Aufruf wie Util.random("Kino", "Lesen"); lässt der Compiler korrekterweise durch.
Sinnvoll ist diese Einschränkung, wenn es Schnittstellen sind, die Methoden vorschreiben, da sich diese direkt nutzen lassen. Das ist logisch, denn bei einer Einschränkung des Typs wird der Compiler sicherstellen, dass die konkreten Typen die vorgeschriebene Schnittstelle haben und damit die Methoden existieren.
Nehmen wir an, wir wollten ein typsicheres max() implementieren. Es soll den größeren der beiden Werte zurückgeben. Vergleiche lassen sich einfach tätigen, wenn die Objekte Comparable implementieren, denn compareTo() liefert einen Rückgabewert, der aussagt, welches Objekt nach der definierten Metrik kleiner, größer oder gleich ist.
public static <T extends Comparable> T max( T m, T n )
{
return m.compareTo( n ) > 0 ? m : n;
}Die Nutzung ist einfach:
System.out.println( Util.max( "Kino", "Lesen" ) ); // Lesen System.out.println( Util.max( new Integer(12), new Integer(100) ) ); // 100
Einschränkung mit super
Neben extends kann der Typ auch mit super eingeschränkt werden. Dann sind nicht mehr alle Untertypen erlaubt, sondern der genannte Typ bestimmt den maximalen Obertyp. Während also <T extends CharSequence> eine Typisierung mit Klassen ermöglicht, die CharSequence implementieren, also mindestens vom Typ CharSequence sind, würde <T super String> die Typen einschließen, die in der Vererbungshierarchie unter String liegen. Die Einschränkung ist wenig nötig und im Allgemeinen für Wildcards sinnvoll, die wir gleich kennenlernen werden.
Weitere Obertypen mit &
Soll der konkrete Typ zu mehreren Typen passen, lassen sich mit einem & weitere Obertypen hinzunehmen. Wichtig ist aber, dass nur eine Klassen-Vererbungsangabe stattfinden kann, also nur ein extends stehen darf, da Java keine Mehrfachvererbung auf Klassenebene unterstützt. Der Rest müssen implementierte Schnittstellen sein.
Nehmen wir eine Oberklasse O und Schnittstellen I1 und I2 an. Dann sind die folgenden Deklarationen erlaubt:
- <T extends O>
- <T extends I1 & I2>
- <T extends O & I1>
- <T extends O & I1 & I2>
Falsch wäre etwa <T extends O1 & T extends O2>.
6.12.5 Generics und Vererbung, Invarianz
Im Zusammenhang mit Generics und Vererbung muss beachtet werden, dass die übliche Substitution nicht funktioniert. Wenn Player eine Unterklasse von GameObject ist, so ist Box<Player> keine Unterklasse von Box<GameObject>, genauso wie Box<Object> nicht die Oberklasse von Box<GameObject> ist beziehungsweise eine Box, die alle erdenklichen Typen ermöglicht.
Der Compiler meckert bei diesem Versuch sofort:
Box<Object> box; box = new Box<GameObject>(); // incompatible types
Die Erklärung ist schnell an einem Beispiel gezeigt. Da nun die Box in setValue() alles vom Typ Object aufnimmt – und ein String ist ein Object –, scheint folgender Argumenttyp zu funktionieren:
box.setValue( "Invarianz" );
Doch da die Box tatsächlich mit Spielobjekten aufgebaut wurde, passt der String hier nicht hinein.
Die Ableitungsbeziehung zwischen Typargumenten überträgt sich folglich nicht auf generische Klassen. Das wäre ein Fehler, und daher gibt es keine Kovarianz bei Generics; die Tatsache nennt sich Invarianz. Bei Funktionsaufrufen ist das besonders lästig, doch werden wir später mit den Wildcards eine Lösung kennenlernen. Es wird damit
void out( Box<GameObject> g )
nur eine Box mit GameObject aufnehmen können, aber zum Beispiel keine Box<Player>.
6.12.6 Wildcards
Ein bewusstes »Vergessen« der Typinformationen lässt sich durch das Wildcard ? erreichen. Es erlaubt aber auch, verschiedene Unterklassen zusammenzuführen. Wir haben schon oben gesehen, dass etwa Folgendes nicht funktioniert:
Listing 6.106 com/tutego/insel/generics/GenericBoxExample4.java, Ausschnitt
Box<Number> numberBox; Box<Integer> bI = new Box<Integer>(); Box<Double> bD = new Box<Double>(); numberBox = bI; // Compilerfehler Type mismatch
Über Wildcards ist es jedoch möglich, den Typ von numberBox frei zu lassen, was jetzt aber nicht so gemeint ist, dass wir die Box gänzlich ohne generische Syntax deklarieren, sondern als:
Box<?> b;
Das Fragezeichen in der Angabe steht für alle Boxen und für alle Untertypen T im Fall von Box<T>. Es ist wichtig zu verstehen, dass ? nicht für Object steht, sondern für einen unbekannten Typ!
Da die Wildcards auch mit Typeinschränkung arbeiten, können wir auf diese Weise eine Box von Number-Objekten aufbauen:
Box<? extends Number> numberBox; Box<Integer> intBox = new Box<Integer>(); Box<Double> doubleBox = new Box<Double>(); Box<String> stringBox = new Box<String>();
Die Schreibweise <? extends Klasse> nennt sich upper bound wildcard. (Eine Einschränkung der Art <? super Klasse> heißt lower bound wildcard.) So funktioniert die Zuweisung:
numberBox = intBox; // oder numberBox = doubleBox;
Aber nicht so:
numberBox = stringBox; // Type mismatch
Die Nutzung der numberBox ist jedoch insofern eingeschränkt, als das setValue() nur über die konkrete Box, also etwa intBox, funktioniert, aber nicht über die allgemeine numberBox. Der Zugriff ist unproblematisch.
numberBox.setValue( 1 ); // Compilerfehler intBox.setValue( 1 ); Number number = numberBox.getValue(); System.out.println( number ); // 1
Weitere Anwendungen der upper bound wildcard und lower bound wildcard beschreibt das Kapitel 12 über Datenstrukturen.