Number parametrisiert zu sein scheint und die add()-Methode daher jeden Parameter akzeptiert, der zuweisungskompatibel zu Number ist. Da numList ja aber nur auf das Vector<Integer>-Objekt referenziert, wäre in diesem so ein Double-Objekt angekommen, obwohl dies natürlich nicht erwünscht war.list parametrisiert wurde, kann er für die add()-Methode nicht den Typ des nötigen Parameters bestimmen. Das einzige, was er zulassen kann, ist der Wert null, da dieser quasi Subtyp aller Klassen ist: Egal, mit welchem Typ das Objekt, auf das list referenziert, parametrisiert wurde, null kann immer eingefügt werden.get()-Methode:
get() geliefert werden, garantieren, außer dass sie zuweisungskompatibel zu Object sind (dies gilt für jedes konkrete Objekt).
extends bzw. super:
list definiert und für den Typparameter festgelegt, dass dieser Number oder aber eine Unterklasse von Number sein muss. Diese Bedingung erfüllt das Objekt, das von intList referenziert wird, so dass die Zuweisung hier erlaubt ist.Number ist. Daher liefert die get()-Methode nun auch nur eine Number-Referenz (Zeile 6). null. Dies mag überraschen, ist aber auch leicht einsichtig: Im "schlimmsten" Fall ist der aktuelle Parameter eben nicht Number, sondern ein speziellerer Typ, z. B. Integer oder Double. Da dies alles nicht zugesichert werden kann, kann wieder nur der Wert eingefügt werden, der zuweisungskompatibel zu allen Typen ist.super hat umgekehrte Auswirkungen:
Number parametrisiert ist und somit neben Integer-Objekten auch Double-, Long- und andere Objekte akzeptiert. Beispielhaft wird in Zeile 2 ein Integer-Objekt eingefügt. Integer oder einer Oberklasse davon (also bis einschließlich Object) parametrisiert wurde. Diese Bedingung erfüllt das Objekt, das von numList referenziert wird, so dass die Zuweisung erlaubt ist.Object sind (dies wäre ja der "schlimmste" Parameter, den man annehmen könnte). Daher liefert die get()-Methode auch nur eine Object-Referenz (Zeile 7).Integer-Referenzen akzeptiert (theoretisch auch Unterklassen von Integer, also alles, was zuweisungskompatibel zum Typ Integer ist), da dies wiederum der speziellste Typ ist, der hätte verwendet werden können. Ließe man allgemeinere Typen zu, bestünde die Möglichkeit, dass ja doch Integer als Typparameter verwendet wurde, und somit das Typsystem umgangen wäre.super verwirren. Anwendungsbeispiele sind hier viel seltener als beim Schlüsselwort extends. Im Ausblick im letzten Kapitel wird dies noch einmal kurz angeschnitten. Number, um alle Zahlentypen gleichzeitig zuzulassen, oder auch mit einem spezielleren Zahlentyp. Für den Typparameter heißt dies, dass er immer mindestens Number oder eine Unterklasse sein muss. Die Klasse könnte wie folgt aussehen:
Number oder eine Unterklasse sein muss. Daher kann in der Summationsfunktion in Zeile 28 vorausgesetzt werden, dass die Objektvariable value auf jeden Fall die Methode doubleValue() implementiert, und diese direkt aufgerufen werden. Die Summation selbst erfolgt rekursiv.Comparable nutzen, dass von den konkreten Zahlenklassen wie Integer usw. implementiert wird, jedoch nicht von der abstrakten Basisklasse Number.Comparable selbst ist ebenfalls ein generisches Interface. Es kann nur Objekte gleichen Typs vergleichen:
So implementiert die Klasse Integer das Interface Comparable<Integer>, kann also nur gegen andere Integer-Objekte verglichen werden. Allgemein heißt dies, dass der Typ E, über den die Liste parametrisiert wird, einmal den Typen Number "implementieren" und einmal die Schnittstelle Comparable<E> zur Verfügung stellen muss. Diese Mehrfachvererbung spezifiziert man mit einem &:
value die Methode compareTo() zur Verfügung stellt. Number nun nicht mehr die Bedingungen für den Typparameter erfüllt; mit diese Klasse können also nur noch "homogene" Listen von Integer-, Long- oder anderen konkreten Zahlenklassen gebildet werden.
Array, die mit dem jeweils verwendeten Typen des Arrays parametrisiert wird. Integer[] wäre also in diesem Gedankenspiel eine andere Schreibweise für Array<Integer>.Integer[] zuweisungskompatibel zu Object[]. Über diesen Weg kann man auch andere Objekte als Integer-Objekte in diesem Array ablegen, was jedoch zur Laufzeit zu einer ArrayStoreException führt. Schon aus diesem Grunde gibt es einige Reibungspunkte zwischen Arrays und Generics in Java. Number oder eine Unterklasse ist.makeSomething festgelegt, dass er ein X-Objekt sein soll, das als Typparameter einen Array von Number-Objekten oder etwas zuweisungskompatibles (also z. B. auch einen Array von Integer-Objekten) verwenden soll. Man sieht also, dass man als Typparameter auch Array-Typen verwenden kann, da sich diese ja in Java wie ein normaler Typ verwenden lassen.