6.13 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 Standard-Konstruktor: 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. Lediglich für einen 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 einem, 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 der Größe byte, short, int, long oder auch Gleitkommazahlen sind – der Algorithmus selbst ist davon nicht berührt.

Ein Algorithmus, der von einem Datentyp unabhängig programmiert werden kann, nennt man generisch und die Möglichkeit, in Java mit generischen Typen zu arbeiten, Generics¹  . 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, aber damit lässt sich leben.

Die Implementierung der Java-Generics basiert auf einem Projekt mit dem Namen Pizza. Später wurde Pizza dann in GJ umbenannt und anschließend wurde dies zur Basis vom Java Specification Request 14: »Add Generic Types To The Java Programming Language«.

6.13.1 Einfache Klassenschablonen 

Wenn wir die StringBox als Basis nehmen, so haben wir bei der Übersetzung der IntBox in die StringBox drei Stellen gefunden, an der wir den Typ ändern müssen. Wollen wir die Box in eine generische Klasse umbauen, so müssen wir an den drei Stellen, an denen String vorkam, von dem speziellen Typ löschen und einen Typ-Stellvertreter einsetzen. Der Name des Stellvertreters muss in der Klassendefinition angegeben werden, denn es kann durchaus mehr als ein Stellvertreter geben. Die Syntax bei den Generics ist für unsere Box folgende:

class Box<T>
{
  private T val;

  void setValue( T val )
  {
    this.val = val;
  }

  T getValue()
  {
    return val;
  }
}

An Stelle des konkreten Typs String steht nun einfach T. Die Definition des Typnamens steht nur einmal zu Beginn der Klasse in eckigen Klammern hinter dem Klassennamen. Die Abkürzung ist gerne T, da es symbolisch für Typ steht.

Um die Box nutzen zu können, müssen wir sie mit einem speziellen Typ erzeugen. Dazu wird hinter dem Klassenamen, wie auch in der Definition der Klasse, in spitzen Klammern der konkrete Typ angeben, etwa String oder Integer oder Point.

Box<String>  stringBox = new Box<String>();
Box<Integer> intBox    = new Box<Integer>();
Box<Point>   pointBox  = new Box<Point>();

Das Schöne dabei 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.

double x = pointBox.getValue().getX();

Typanpassungen

Ein mit Generics spezifizierter Typ lässt sich durch Typanpassung auf eine allgemeine Form bringen.

List<Integer> list = new ArrayList<Integer>();
List nixMitGenericsList = (List) list;

Bei der nixMitGenericsList 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 Compilezeit und so kann über die Hintertür ein falscher Typ in die Datenstruktur kommen.

nixMitGenericsList.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.

6.13.2 Einfache Methodenschablonen 

Eine Klasse kann ganz normal ohne Schablone definiert 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 zufall( T m, T n )
  {
    return Math.random() > 0.5 ? m : n;
  }
}

Hier wird die Funktion zufall() auf einem beliebigen Typ deklariert; die Angabe von <T> beim Klassennamen entfällt und verschiebt sich auf die Definition der Methode.

Die Benutzung kann ohne Angabe des Typs – aber doch überprüft – geschehen:

String s = Util.zufall( "Essen", "Schlafen" );

Geben wir an Stelle eines Strings den Typ Integer an, so wird der Compiler einen Fehler melden.

6.13.3 Generics und Vererbung 

In Zusammenhang mit Generis und Vererbung muss beachtet werden, dass die übliche Substitution nicht funktioniert. Wenn Disko eine Unterklasse von Gebäude ist, so ist Box<Disko> nicht Unterklasse von Box<Gebäude>! Der Compiler meckert aber den Versuch schon an, so dass wir vor der Versuchung gehindert werden.

Box<Gebäude> box;
box = new Box<Disko>();      // incompatible types

Die Erklärung ist schnell an einem Beispiel gezeigt. Nehmen wir noch eine Kirche dazu und halten in Erinnerung, dass Kirche und Disko beides Unterklassen von Gebäude sind. Da nun die Box in setValue() alles vom Typ Gebäude aufnimmt – und Kirchen und Diskotheken sind Gebäude – würde erst einmal funktionieren:

box.setValue( new Kirche() );

Doch da die Box tatsächlich mit Diskotheken aufgebaut wurde, passt die Kirche hier nicht rein. Verändern wir die Initialisierung der Box in box = new Box<Disko>(); funktioniert das natürlich wieder.

6.13.4 Einschränken der Typen 

Bei der Definition einer Schablone können die Typen weiter eingeschränkt werden. Es kann vorgeschrieben werden, dass der Typ eine konkrete Schnittstelle implementieren muss. Unsere Definition von zufall() sah keine Einschränkungen vor, sodass auch zum Beispiel folgendes möglich ist:

Serializable s1 = new Serializable() { };
Serializable s2 = new Point();

Util.zufall( s1, s2 );

Da der Typ beliebig ist, können auch Objekte aufgenommen werden, die vielleicht wenig Sinn machen, wie unsere Klassen, die lediglich Serializable implementieren.

Einschränkung mit extends

Um das zu vermeiden, kann bei der Deklaration der Typ eingeschränkt werden. Wollen wir nur Klassen, die CharSequence implementieren (also Zeichenfolgen wie String und StringBuffer/StringBuilder), so schreiben wir das in die Definition mit hinein.

public static <T extends CharSequence> T zufall( T m, T n )
{
  return Math.random() > 0.5 ? m : n;
}

Jetzt wird der Compiler mit übergebenen Serializable einen Fehler melden. Ein Aufruf wie Util.zufall( "Kino", "Lesen" ); lässt der Compiler korrekterweise durch.

Sinnvoll ist diese Einschränkung, wenn es Schnittstellen sind, die Methoden vorschreiben, denn diese lassen sich direkt nutzen. 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 auch mit super der Typ 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 wird so wenig benötigt und ist im Allgemeinen sinnvoll für Wildcards, die wir gleich kennen lernen werden.

Weitere Obertypen mit &

Soll der konkrete Typ zu mehreren Typen passen, lässt sich mit einem & noch weiteren Obertypen hinzunehmen. Wichtig ist, dass aber nur eine Klassen-Vererbungsangabe stattfinden kann, also nur ein extends stehen darf. Der Rest müssen implementierte Schnittstellen sein. Nehmen wir eine Oberklasse O und Schnittstellen I1 und I2 an. Dann sind folgende 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.13.5 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 statt 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, denn sie muss nicht auf die Generics großartig angepasst werden, aber sonst ist es ein riesiges Problem, denn die Typinformationen sind dann nicht zur Laufzeit vorhanden. Das müssen Programmierer wissen, denn so funktioniert zum Beispiel der instanceof-Oerator auch nicht so:

Box<String> stringBox = new Box<String>();

if( stringBox instanceof Box<Number> )       
// illegal generic type for instanceof
  System.out.println( "Jepp" );

Der Compiler meldet zu Recht einen Fehler, denn den Typ Box<String> sowie Box<Number> gibt es zur Laufzeit gar nicht – es sind nur typgelöschte Box-Objekte. Das zeigt auch das folgende Beispiel:

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, und sie haben Generizität in der Common Language Runtime (CLR) vorgesehen. Microsoft ist damit einen klaren Schritt voraus.

Raw-Type

Generischen Klassen müssen nicht unbedingt parametrisiert werden; sie sind dem Datentyp Object weiterhin gütig. Das ist auch wichtig, denn sonst könnten viele parametrisierte neue Klassen nicht mehr mit altem Programmcode verwendet werden.

Box stringBox = new Box<String>();
Box objectBox = new Box();

Ein parametrisierter Typ ohne Typ nennt sich Raw-Type. In unserem Beispiel ist Box der Raw-Type von Box<T>. Raw-Types bieten die gleiche Funktionalität wie auch parametrierte Typen, nur dann nicht überprüft. Im ersten Fall liefert getValue() den korrekten Typ String, im zweiten Fall nur Object, denn im zweiten Fall fehlt jeder Bezug zum Typ.

Doch was ist eigentlich mit setValue()? 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, doch in diesem Fall gibt der Compiler eine Warnung.

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 ist, dass die Box hätte typisiert werden müssen. Achten wir darauf nicht, kann es schnell zu Problemen führen:

Box<String> stringBox = new Box<String>();
Box         objectBox = stringBox;

Der Compiler gibt keinen Fehler und auch keine Warnung. 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 objectBox in Wirklichkeit ein typgelöschter Verweis auf die String-Box ist, haben wir ein Typproblem:

objectBox.setValue( new java.util.Date() );   
// Warnung vor der Unsafe type operation
System.out.println( stringBox.getValue() );   
// führt zu einer ClassCastException

6.13.6 Wildcards 

Ein bewusstes »Vergessen« der Typinformationen lässt sich durch das Wildcard ? erreichen. Es erlaubt, verschiedene Unterklassen zusammenzuführen. Wir haben schon oben gesehen, dass etwa folgendes nicht funktioniert:

Box<Number>  b;
Box<Integer> bI = new Box<Integer>();
Box<Double>  bD = new Box<Double>();
b = bI;                                   // Nein

Über Wildcard ist es jedoch möglich, den Typ von b frei zu lassen. Da ist jetzt aber nicht so gemeint, dass wir die Box als Box b definieren, 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> b;
Box<Integer> bI = new Box<Integer>();
Box<Double>  bD = new Box<Double>();
Box<String>  bS = 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 wird funktionieren:

b = bI;   // oder b = bD

Aber nicht:

b = bS;

Bei den Raw-Types haben wir einen Fall diskutiert, dass ja diese Schreibweise eigentlich verboten gehört, da wir sonst etwa über eine konkrete Integer-Box ein Double einlesen können, was zur einem Laufzeitfehler führen würde. Mit den Wildcards wird das aber verhindert:

Upper bound wildcards erlauben keine Methodenaufrufe, die einen parametrisierten Typ als Parameter enthalten. Lesende Funktionen, also Funktionen, die einen parametrisierten Typ zurückgeben, sind dagegen erlaubt.

Lower bound wildcards erlauben Methodenaufrufe, die einen parametrisierten Typ enthalten, aber keine Methoden, die einen parametrisierten Typ zurückgeben.

¹  In C++ werden diese Typen von Klassen parametrisierte Klassen, oder auch Templates (Schablonen) genannt.