Generische Programmierung in Java - Versionsgeschichte

Siegbert v2: Generics werden im Buch "Java ist auch eine Insel" aktuell im Kapitel 12 behandelt / Anmerkung zum Diamant-Operator ergänzt / Belege hinzugefügt bzw. überarbeitet

2025-04-11T16:50:37Z

Generics werden im Buch "Java ist auch eine Insel" aktuell im Kapitel 12 behandelt / Anmerkung zum Diamant-Operator ergänzt / Belege hinzugefügt bzw. überarbeitet

← Nächstältere Version		Version vom 11. April 2025, 18:50 Uhr
Zeile 1:		Zeile 1:
	'''[[Generische Programmierung]] in [[Java (Programmiersprache)\|Java]]''' wird durch sog. ''Generics'' seit Java 1.5 ermöglicht. Der Begriff steht synonym für „parametrisierte Typen“. Die Idee dahinter ist, zusätzliche Variablen für Typen einzuführen. Diese ''Typ-Variablen'' repräsentieren zum Zeitpunkt der Implementierung unbekannte Typen. Erst bei der Verwendung der Klassen, Schnittstellen und Methoden werden diese Typ-Variablen durch konkrete Typen ersetzt. Damit kann typsichere Programmierung meistens gewährleistet werden. Jedoch nicht immer.<ref>{{~~cite~~ ~~web~~\|~~url~~=https://raw.githubusercontent.com/namin/unsound/master/doc/unsound-oopsla16.pdf\|~~title~~=~~Java~~ ~~and~~ ~~Scala’s Type Systems are Unsound~~}}</ref>		'''[[Generische Programmierung]] in [[Java (Programmiersprache)\|Java]]''' wird durch sog. ''Generics'' seit Java 1.5 ermöglicht. Der Begriff steht synonym für „parametrisierte Typen“. Die Idee dahinter ist, zusätzliche Variablen für Typen einzuführen. Diese ''Typ-Variablen'' repräsentieren zum Zeitpunkt der Implementierung unbekannte Typen. Erst bei der Verwendung der Klassen, Schnittstellen und Methoden werden diese Typ-Variablen durch konkrete Typen ersetzt. Damit kann typsichere Programmierung meistens gewährleistet werden. Jedoch nicht immer.<ref>{{Literatur \|Autor=Nada Amin, Ross Tate \|Titel=Java and Scala’s Type Systems are Unsound: The Existential Crisis of Null Pointers \|Hrsg=ACM \|Sammelwerk=[[OOPSLA]] 2016 \|Ort=New York \|Datum=2016 \|Sprache=en \|ISBN=9781450344449 \|Seiten=838–848 \|Online=https://raw.githubusercontent.com/namin/unsound/master/doc/unsound-oopsla16.pdf \|Format=PDF \|KBytes=215 \|Abruf=2017-03-31}}</ref>

	== Das Konzept ==		== Das Konzept ==
Zeile 51:		Zeile 51:
	List<JButton> list = new ArrayList<>();		List<JButton> list = new ArrayList<>();
	</syntaxhighlight>		</syntaxhighlight>
			Die beiden leeren spitzen Klammern werden aufgrund ihrer Form auch als ''Diamant-Operator'' ({{enS\|Diamond-Operator}}) bezeichnet.<ref>{{Literatur \|Autor=Joachim Goll, Cornelia Heinisch \|Titel=Java als erste Programmiersprache: Grundkurs für Hochschulen \|Auflage=8 \|Verlag=Springer \|Ort=Wiesbaden \|Datum=2016 \|Sprache=de \|ISBN=9783658121174 \|Seiten=725}}</ref><ref>{{Literatur \|Autor=Reinhard Schiedermeier \|Titel=Programmieren mit Java \|Auflage=2 \|Verlag=Pearson Studium \|Ort=München \|Datum=2010 \|Sprache=de \|ISBN=9783868940312 \|Seiten=375}}</ref>

	Durch Kombination von generischen Typen mit den erweiterten For-Schleifen lässt sich obiges Beispiel kürzer fassen:		Durch Kombination von generischen Typen mit den erweiterten For-Schleifen lässt sich obiges Beispiel kürzer fassen:
Zeile 221:		Zeile 222:
	* Ina Brenner: [http://www.theserverside.de/java-generics-generische-methoden-klassen-und-interfaces/ Tutorial zu Generics in Java] von der Autorin eines Buchs zur Java-Zertifizierung SCJP (deutsch)		* Ina Brenner: [http://www.theserverside.de/java-generics-generische-methoden-klassen-und-interfaces/ Tutorial zu Generics in Java] von der Autorin eines Buchs zur Java-Zertifizierung SCJP (deutsch)
	* Klaus Kreft, Angelika Langer: [http://www.angelikalanger.com/Articles/Topics.html#JavaGenerics/ Artikelserie zu Generics in Java] im JavaSpektrum (deutsch)		* Klaus Kreft, Angelika Langer: [http://www.angelikalanger.com/Articles/Topics.html#JavaGenerics/ Artikelserie zu Generics in Java] im JavaSpektrum (deutsch)
	*[https://openbook.rheinwerk-verlag.de/javainsel/~~11_001~~.html~~#u11~~ Kapitel zu Generischen Datentypen] aus dem Galileo-Openbook ''Java ist auch eine Insel'' (deutsch)		*[[Christian Ullenboom]]: [https://openbook.rheinwerk-verlag.de/javainsel/12_001.html Kapitel zu Generischen Datentypen] aus dem Galileo-Openbook ''Java ist auch eine Insel'' (deutsch)

	== Einzelnachweise ==		== Einzelnachweise ==

2A03:7846:CA65:101:DC9F:BD5C:BE3:ED0: /* Weblinks */

2022-01-17T13:54:46Z

Weblinks

← Nächstältere Version		Version vom 17. Januar 2022, 15:54 Uhr
Zeile 221:		Zeile 221:
	* Ina Brenner: [http://www.theserverside.de/java-generics-generische-methoden-klassen-und-interfaces/ Tutorial zu Generics in Java] von der Autorin eines Buchs zur Java-Zertifizierung SCJP (deutsch)		* Ina Brenner: [http://www.theserverside.de/java-generics-generische-methoden-klassen-und-interfaces/ Tutorial zu Generics in Java] von der Autorin eines Buchs zur Java-Zertifizierung SCJP (deutsch)
	* Klaus Kreft, Angelika Langer: [http://www.angelikalanger.com/Articles/Topics.html#JavaGenerics/ Artikelserie zu Generics in Java] im JavaSpektrum (deutsch)		* Klaus Kreft, Angelika Langer: [http://www.angelikalanger.com/Articles/Topics.html#JavaGenerics/ Artikelserie zu Generics in Java] im JavaSpektrum (deutsch)
	*[~~http~~://openbook.rheinwerk-verlag.de/javainsel/~~10_001~~.html#~~u10~~ Kapitel zu Generischen Datentypen] aus dem Galileo-Openbook ''Java ist auch eine Insel'' (deutsch)		*[https://openbook.rheinwerk-verlag.de/javainsel/11_001.html#u11 Kapitel zu Generischen Datentypen] aus dem Galileo-Openbook ''Java ist auch eine Insel'' (deutsch)

	== Einzelnachweise ==		== Einzelnachweise ==

Diaspomod: /* Praktische Beispiele */ Form.

2019-09-11T20:47:24Z

Praktische Beispiele: Form.

Änderungen zeigen

Diaspomod: Readability.

2019-05-31T12:53:01Z

Readability.

← Nächstältere Version		Version vom 31. Mai 2019, 14:53 Uhr
Zeile 25:		Zeile 25:
	list.add(new JButton("Button 4"));		list.add(new JButton("Button 4"));
	list.add(new JButton("Button 5"));		list.add(new JButton("Button 5"));
		⚫
	for (int i = 0; i < list.size(); i++) {		for (int i = 0; i < list.size(); i++) {
	JButton button = (JButton)list.get(i);		JButton button = (JButton) list.get(i);
	button.setBackground(Color.white);		button.setBackground(Color.white);
	}		}
Zeile 40:		Zeile 41:
	list.add(new JButton("Button 4"));		list.add(new JButton("Button 4"));
	list.add(new JButton("Button 5"));		list.add(new JButton("Button 5"));
		⚫
	for (int i = 0; i < list.size(); i++) {		for (int i = 0; i < list.size(); i++)
	list.get(i).setBackground(Color.white);		list.get(i).setBackground(Color.white);
⚫	}
	</syntaxhighlight>		</syntaxhighlight>
	Beim Auslesen ist nun keine explizite Typumwandlung mehr notwendig, beim Speichern ist es nur noch möglich, JButtons in der <code>ArrayList</code> ''list'' abzulegen.		Beim Auslesen ist nun keine explizite Typumwandlung mehr notwendig, beim Speichern ist es nur noch möglich, JButtons in der <code>ArrayList</code> ''list'' abzulegen.
Zeile 59:		Zeile 60:
	list.add(new JButton("Button 4"));		list.add(new JButton("Button 4"));
	list.add(new JButton("Button 5"));		list.add(new JButton("Button 5"));

	for (JButton b : list) {		for (JButton b: list)
	b.setBackground(Color.white);		b.setBackground(Color.white);
⚫	}
	</syntaxhighlight>		</syntaxhighlight>
	Ein Beispiel für eine generische Klasse, die zwei Objekte von beliebigem, aber einander gleichem Typ beinhaltet, liefert der folgende Beispielcode:		Ein Beispiel für eine generische Klasse, die zwei Objekte von beliebigem, aber einander gleichem Typ beinhaltet, liefert der folgende Beispielcode:
Zeile 68:		Zeile 69:
	private T object1;		private T object1;
	private T object2;		private T object2;

	public DoubleObject(T object1,T object2) {		public DoubleObject(T object1,T object2) {
	this.object1 = object1;		this.object1 = object1;
	this.object2 = object2;		this.object2 = object2;
	}		}

	public String toString() {		public String toString() {
	return this.object1 + ", " + this.object2;		return this.object1 + ", " + this.object2;
	}		}

	public static void main(String[] args) {		public static void main(String[] args) {
	DoubleObject<String> s = new DoubleObject<>("abc","def");		DoubleObject<String> s = new DoubleObject<>("abc","def");

2A02:908:1A72:7800:A8A7:14A5:3C5:6E68: Link aktualisiert

2018-07-18T08:34:33Z

Link aktualisiert

← Nächstältere Version		Version vom 18. Juli 2018, 10:34 Uhr
Zeile 205:		Zeile 205:
	* Ina Brenner: [http://www.theserverside.de/java-generics-generische-methoden-klassen-und-interfaces/ Tutorial zu Generics in Java] von der Autorin eines Buchs zur Java-Zertifizierung SCJP (deutsch)		* Ina Brenner: [http://www.theserverside.de/java-generics-generische-methoden-klassen-und-interfaces/ Tutorial zu Generics in Java] von der Autorin eines Buchs zur Java-Zertifizierung SCJP (deutsch)
	* Klaus Kreft, Angelika Langer: [http://www.angelikalanger.com/Articles/Topics.html#JavaGenerics/ Artikelserie zu Generics in Java] im JavaSpektrum (deutsch)		* Klaus Kreft, Angelika Langer: [http://www.angelikalanger.com/Articles/Topics.html#JavaGenerics/ Artikelserie zu Generics in Java] im JavaSpektrum (deutsch)
	* [http://openbook.~~galileocomputing~~.de/javainsel/~~javainsel_09_001~~.html Kapitel zu Generischen Datentypen] aus dem Galileo-Openbook ''Java ist auch eine Insel'' (deutsch)		*[http://openbook.rheinwerk-verlag.de/javainsel/10_001.html#u10 Kapitel zu Generischen Datentypen] aus dem Galileo-Openbook ''Java ist auch eine Insel'' (deutsch)

	== Einzelnachweise ==		== Einzelnachweise ==

Regenspaziergang: /* Das Konzept */

2018-06-17T07:12:48Z

Das Konzept

← Nächstältere Version		Version vom 17. Juni 2018, 09:12 Uhr
Zeile 5:		Zeile 5:
	Damit werden der Sprache einige ähnliche Möglichkeiten eröffnet, die sich vergleichbar bei den [[Template (Programmierung)\|Templates]] in [[C++]] bieten.		Damit werden der Sprache einige ähnliche Möglichkeiten eröffnet, die sich vergleichbar bei den [[Template (Programmierung)\|Templates]] in [[C++]] bieten.

	Prinzipiell gibt es aber durchaus wesentliche Unterschiede. Während in ~~C++~~ über die ''Schnittstelle'' der Typparameter parametrisiert wird, wird in ~~Java~~ direkt über den ''Typ'' des Typparameters selbst parametrisiert. Der Quelltext eines C++-Templates muss für den Anwender (d. h. beim Einsetzen des Typparameters) verfügbar sein, während ein generischer Java-Typ auch als übersetzter Bytecode veröffentlicht werden kann. Für verschiedene konkret verwendete Typparameter produziert der Compiler duplizierten Zielcode.		Prinzipiell gibt es aber durchaus wesentliche Unterschiede. Während in Java über die ''Schnittstelle'' der Typparameter parametrisiert wird, wird in C++ direkt über den ''Typ'' des Typparameters selbst parametrisiert. Der Quelltext eines C++-Templates muss für den Anwender (d. h. beim Einsetzen des Typparameters) verfügbar sein, während ein generischer Java-Typ auch als übersetzter Bytecode veröffentlicht werden kann. Für verschiedene konkret verwendete Typparameter produziert der Compiler duplizierten Zielcode.

	Beispielsweise bietet die Funktion std::sort in C++ die Möglichkeit, alle Container zu sortieren, die bestimmte Methoden anbieten (hier speziell begin() und end(), die jeweils einen Iterator liefern) und deren Typparameter den 'operator<' implementiert (oder explizit eine andere Vergleichsfunktion angegeben wurde). Ein Nachteil, der sich durch dieses System ergibt, ist die (für den Programmierer!) schwierigere Übersetzung. Der Compiler hat keine andere Möglichkeit, als den Typparameter in jedem Fall durch den geforderten konkreten Typ zu ersetzen und den ganzen Code erneut zu kompilieren.		Beispielsweise bietet die Funktion std::sort in C++ die Möglichkeit, alle Container zu sortieren, die bestimmte Methoden anbieten (hier speziell begin() und end(), die jeweils einen Iterator liefern) und deren Typparameter den 'operator<' implementiert (oder explizit eine andere Vergleichsfunktion angegeben wurde). Ein Nachteil, der sich durch dieses System ergibt, ist die (für den Programmierer!) schwierigere Übersetzung. Der Compiler hat keine andere Möglichkeit, als den Typparameter in jedem Fall durch den geforderten konkreten Typ zu ersetzen und den ganzen Code erneut zu kompilieren.

2A02:810D:26C0:C:3C04:4F2B:3AB8:8B3D am 24. März 2018 um 13:46 Uhr

2018-03-24T13:46:51Z

← Nächstältere Version		Version vom 24. März 2018, 15:46 Uhr
Zeile 78:		Zeile 78:
	DoubleObject<String> s = new DoubleObject<>("abc","def");		DoubleObject<String> s = new DoubleObject<>("abc","def");
	DoubleObject<Integer> i = new DoubleObject<>(123,456);		DoubleObject<Integer> i = new DoubleObject<>(123,456);
	System.out.println("DoubleObject<String> s=" + s);		System.out.println("DoubleObject<String> s=" + s.toString());
	System.out.println("DoubleObject<Integer> i=" + i);		System.out.println("DoubleObject<Integer> i=" + i.toString());
	}		}
	}		}

2003:A:24:1B00:921B:EFF:FE3C:5F17: Kein Denglisch

2018-03-21T19:48:56Z

Kein Denglisch

← Nächstältere Version		Version vom 21. März 2018, 21:48 Uhr
Zeile 5:		Zeile 5:
	Damit werden der Sprache einige ähnliche Möglichkeiten eröffnet, die sich vergleichbar bei den [[Template (Programmierung)\|Templates]] in [[C++]] bieten.		Damit werden der Sprache einige ähnliche Möglichkeiten eröffnet, die sich vergleichbar bei den [[Template (Programmierung)\|Templates]] in [[C++]] bieten.

	Prinzipiell gibt es aber durchaus wesentliche Unterschiede. Während in C++ über die ''Schnittstelle'' der Typparameter parametrisiert wird, wird in Java direkt über den ''Typ'' des Typparameters selbst parametrisiert. Der Quelltext eines C++-Templates muss für den Anwender (d. h. beim Einsetzen des Typparameters) verfügbar sein, während ein generischer Java-Typ auch als übersetzter Bytecode veröffentlicht werden kann. Für verschiedene ~~aktuelle~~ Typparameter produziert der Compiler duplizierten Zielcode.		Prinzipiell gibt es aber durchaus wesentliche Unterschiede. Während in C++ über die ''Schnittstelle'' der Typparameter parametrisiert wird, wird in Java direkt über den ''Typ'' des Typparameters selbst parametrisiert. Der Quelltext eines C++-Templates muss für den Anwender (d. h. beim Einsetzen des Typparameters) verfügbar sein, während ein generischer Java-Typ auch als übersetzter Bytecode veröffentlicht werden kann. Für verschiedene konkret verwendete Typparameter produziert der Compiler duplizierten Zielcode.

	Beispielsweise bietet die Funktion std::sort in C++ die Möglichkeit, alle Container zu sortieren, die bestimmte Methoden anbieten (hier speziell begin() und end(), die jeweils einen Iterator liefern) und deren Typparameter den 'operator<' implementiert (oder explizit eine andere Vergleichsfunktion angegeben wurde). Ein Nachteil, der sich durch dieses System ergibt, ist die (für den Programmierer!) schwierigere Übersetzung. Der Compiler hat keine andere Möglichkeit, als den Typparameter in jedem Fall durch den geforderten konkreten Typ zu ersetzen und den ganzen Code erneut zu kompilieren.		Beispielsweise bietet die Funktion std::sort in C++ die Möglichkeit, alle Container zu sortieren, die bestimmte Methoden anbieten (hier speziell begin() und end(), die jeweils einen Iterator liefern) und deren Typparameter den 'operator<' implementiert (oder explizit eine andere Vergleichsfunktion angegeben wurde). Ein Nachteil, der sich durch dieses System ergibt, ist die (für den Programmierer!) schwierigere Übersetzung. Der Compiler hat keine andere Möglichkeit, als den Typparameter in jedem Fall durch den geforderten konkreten Typ zu ersetzen und den ganzen Code erneut zu kompilieren.

MightyMaz am 5. März 2018 um 09:37 Uhr

2018-03-05T09:37:34Z

Aka: Tippfehler entfernt

2017-05-08T18:57:43Z

Tippfehler entfernt

← Nächstältere Version		Version vom 8. Mai 2017, 20:57 Uhr
Zeile 11:		Zeile 11:
	Sehr leicht können bei unpassenden Typparametern und anderen Problemen komplizierte und unverständliche Compiler-Meldungen entstehen, was einfach mit der Tatsache zusammenhängt, dass die konkreten Anforderungen an die Typparameter unbekannt sind. Die Arbeit mit C++-Templates erfordert deshalb eine lückenlose Dokumentation der Anforderungen an einen Typparameter. Durch Template-[[Metaprogrammierung]] können die meisten Anforderungen (Basisklasse, Vorhandensein von Methoden, Kopierbarkeit, Zuweisbarkeit etc.) auch in speziellen Konstrukten abgefragt werden, wodurch sich lesbarere Fehlermeldungen ergeben. Obgleich sie standardkonform sind, werden diese Konstrukte jedoch nicht von allen [[Compiler]]n unterstützt.		Sehr leicht können bei unpassenden Typparametern und anderen Problemen komplizierte und unverständliche Compiler-Meldungen entstehen, was einfach mit der Tatsache zusammenhängt, dass die konkreten Anforderungen an die Typparameter unbekannt sind. Die Arbeit mit C++-Templates erfordert deshalb eine lückenlose Dokumentation der Anforderungen an einen Typparameter. Durch Template-[[Metaprogrammierung]] können die meisten Anforderungen (Basisklasse, Vorhandensein von Methoden, Kopierbarkeit, Zuweisbarkeit etc.) auch in speziellen Konstrukten abgefragt werden, wodurch sich lesbarere Fehlermeldungen ergeben. Obgleich sie standardkonform sind, werden diese Konstrukte jedoch nicht von allen [[Compiler]]n unterstützt.

	Dagegen sind den generischen Klassen und Methoden in Java die Anforderungen ''(engl. constraints)'' an ihre eigenen Typparameter bekannt. Um eine Collection (ohne Comparator) zu sortieren, müssen die enthaltenen Elemente vom Typ Comparable sein, also dieses Interface implementiert haben. Der Compiler muss lediglich prüfen, ob der Typparameter ein Untertyp von Comparable ist, und kann damit schon sicherstellen, dass der Code korrekt ist (d. h. die erforderliche Methode compareTo verfügbar ist). Weiterhin wird ein und derselbe Code für alle konkreten Typen verwendet und nicht ~~jedesmal~~ dupliziert.		Dagegen sind den generischen Klassen und Methoden in Java die Anforderungen ''(engl. constraints)'' an ihre eigenen Typparameter bekannt. Um eine Collection (ohne Comparator) zu sortieren, müssen die enthaltenen Elemente vom Typ Comparable sein, also dieses Interface implementiert haben. Der Compiler muss lediglich prüfen, ob der Typparameter ein Untertyp von Comparable ist, und kann damit schon sicherstellen, dass der Code korrekt ist (d. h. die erforderliche Methode compareTo verfügbar ist). Weiterhin wird ein und derselbe Code für alle konkreten Typen verwendet und nicht jedes Mal dupliziert.

	== Praktische Beispiele ==		== Praktische Beispiele ==

← Nächstältere Version		Version vom 5. März 2018, 11:37 Uhr
Zeile 7:		Zeile 7:
	Prinzipiell gibt es aber durchaus wesentliche Unterschiede. Während in C++ über die ''Schnittstelle'' der Typparameter parametrisiert wird, wird in Java direkt über den ''Typ'' des Typparameters selbst parametrisiert. Der Quelltext eines C++-Templates muss für den Anwender (d. h. beim Einsetzen des Typparameters) verfügbar sein, während ein generischer Java-Typ auch als übersetzter Bytecode veröffentlicht werden kann. Für verschiedene aktuelle Typparameter produziert der Compiler duplizierten Zielcode.		Prinzipiell gibt es aber durchaus wesentliche Unterschiede. Während in C++ über die ''Schnittstelle'' der Typparameter parametrisiert wird, wird in Java direkt über den ''Typ'' des Typparameters selbst parametrisiert. Der Quelltext eines C++-Templates muss für den Anwender (d. h. beim Einsetzen des Typparameters) verfügbar sein, während ein generischer Java-Typ auch als übersetzter Bytecode veröffentlicht werden kann. Für verschiedene aktuelle Typparameter produziert der Compiler duplizierten Zielcode.

	Beispielsweise bietet die Funktion std::sort in C++ die Möglichkeit, alle Container zu sortieren, die bestimmte Methoden anbieten (hier speziell begin() und end(), die jeweils einen Iterator liefern) und deren Typparameter den 'operator<' implementiert (oder explizit eine andere Vergleichsfunktion angegeben wurde). Ein Nachteil, der sich durch dieses System ergibt, ist die (für den Programmierer!) schwierigere Übersetzung. Der Compiler hat keine andere Möglichkeit, als den Typparameter in jedem Fall durch den geforderten konkreten Typ zu ersetzen und den ganzen Code erneut zu ~~compilieren~~.		Beispielsweise bietet die Funktion std::sort in C++ die Möglichkeit, alle Container zu sortieren, die bestimmte Methoden anbieten (hier speziell begin() und end(), die jeweils einen Iterator liefern) und deren Typparameter den 'operator<' implementiert (oder explizit eine andere Vergleichsfunktion angegeben wurde). Ein Nachteil, der sich durch dieses System ergibt, ist die (für den Programmierer!) schwierigere Übersetzung. Der Compiler hat keine andere Möglichkeit, als den Typparameter in jedem Fall durch den geforderten konkreten Typ zu ersetzen und den ganzen Code erneut zu kompilieren.

	Sehr leicht können bei unpassenden Typparametern und anderen Problemen komplizierte und unverständliche Compiler-Meldungen entstehen, was einfach mit der Tatsache zusammenhängt, dass die konkreten Anforderungen an die Typparameter unbekannt sind. Die Arbeit mit C++-Templates erfordert deshalb eine lückenlose Dokumentation der Anforderungen an einen Typparameter. Durch Template-[[Metaprogrammierung]] können die meisten Anforderungen (Basisklasse, Vorhandensein von Methoden, Kopierbarkeit, Zuweisbarkeit etc.) auch in speziellen Konstrukten abgefragt werden, wodurch sich lesbarere Fehlermeldungen ergeben. Obgleich sie standardkonform sind, werden diese Konstrukte jedoch nicht von allen [[Compiler]]n unterstützt.		Sehr leicht können bei unpassenden Typparametern und anderen Problemen komplizierte und unverständliche Compiler-Meldungen entstehen, was einfach mit der Tatsache zusammenhängt, dass die konkreten Anforderungen an die Typparameter unbekannt sind. Die Arbeit mit C++-Templates erfordert deshalb eine lückenlose Dokumentation der Anforderungen an einen Typparameter. Durch Template-[[Metaprogrammierung]] können die meisten Anforderungen (Basisklasse, Vorhandensein von Methoden, Kopierbarkeit, Zuweisbarkeit etc.) auch in speziellen Konstrukten abgefragt werden, wodurch sich lesbarere Fehlermeldungen ergeben. Obgleich sie standardkonform sind, werden diese Konstrukte jedoch nicht von allen [[Compiler]]n unterstützt.
Zeile 114:		Zeile 114:

	Es verhält sich also der Array-Typ bzgl. der Vererbungshierarchie genauso wie der Typparameter.		Es verhält sich also der Array-Typ bzgl. der Vererbungshierarchie genauso wie der Typparameter.
	Kovarianz ist auch mit generischen Typen möglich, allerdings nur mit Einschränkungen, so dass Typfehler zur ~~Compilierzeit~~ ausgeschlossen werden können.		Kovarianz ist auch mit generischen Typen möglich, allerdings nur mit Einschränkungen, so dass Typfehler zur Kompilierzeit ausgeschlossen werden können.

	Referenzen müssen mit der Syntax '''? extends T''' explizit als kovariant gekennzeichnet werden. T heißt ''upper typebound'', also der allgemeinste Typparameter, der erlaubt ist.		Referenzen müssen mit der Syntax '''? extends T''' explizit als kovariant gekennzeichnet werden. T heißt ''upper typebound'', also der allgemeinste Typparameter, der erlaubt ist.
Zeile 125:		Zeile 125:
	((List<Integer>)list).set(index, myInteger); // OK aber Warnung vom Compiler: unchecked cast		((List<Integer>)list).set(index, myInteger); // OK aber Warnung vom Compiler: unchecked cast
	</syntaxhighlight>		</syntaxhighlight>
	Das Ablegen von Elementen in diesen Listen ist nicht möglich, da dies, wie oben beschrieben, nicht typsicher ist (Ausnahme: '''null''' kann abgelegt werden). Bereits zur ~~Compilierzeit~~ tritt ein Fehler auf. Allgemeiner gesagt, ist die Zuweisung		Das Ablegen von Elementen in diesen Listen ist nicht möglich, da dies, wie oben beschrieben, nicht typsicher ist (Ausnahme: '''null''' kann abgelegt werden). Bereits zur Kompilierzeit tritt ein Fehler auf. Allgemeiner gesagt, ist die Zuweisung
	<div>'''?''' → '''? extends T'''</div>		<div>'''?''' → '''? extends T'''</div>
	nicht erlaubt.		nicht erlaubt.