Quelltext der Seite Diskussion:Generische Programmierung in Java

Grats an diejenigen, die diesen Artikel verfasst haben. Wirklich gelungen und auf den ersten Blick (wahrscheinlich auch den zweiten usw.) vollständig :) --[[Benutzer:ChristianHujer|ChristianHujer]] 05:25, 14. Mär 2005 (CET)

''Weiterhin ist es aufgrund dieser Vorgehensweise bei C++ sehr problematisch, virtuelle Methoden im Zusammenhang mit Templates zu verwenden''

:Inwiefern?

''(beispielsweise dürfen Methoden einer template-Klasse nicht virtuell sein).''

:Bullshit. [[Benutzer:Aragorn2|Aragorn2]] 20:40, 26. Mär 2005 (CET)

::Worauf der Autor sich vermutlich unbewusst bezog, ist, dass Template-Methoden nicht virtuell sein dürfen. Bsp.:

 template<typename A, typename B> class Foo {
 public:
     virtual B bar(A someParameter) { /*...*/ }   // ok
 };

::Aber:

 class Is_a_Everything {
 public:
     template<typename ConvertTo>
     virtual operator ConvertTo() const = 0;   // Fehler: virtuelle Template-Methode
 };

::Siehe <nowiki>[</nowiki>Stroustrup, The C++ Programming Language, 3rd edition, Addison Wesley 2000, Abschnitt 13.6.2]
::Nachdem Java auch mit der sogenannten Version "5.0" keine generischen Funktionen vorsieht (nur Methoden generischer Klassen), ist das ein Problem, dass in Java schon allein aufgrund der fehlenden Ausdruckskraft der Sprache gar nicht auftreten kann. Constraints sind eine sinnvolle Ergänzung (in C++ kann man sie bisher nur über Template-[[Metaprogrammierung]] simulieren), die restlichen Einschränkungen von Java Generics gegenüber C++ basieren aber nicht auf (angeblichen) Schwächen von C++-Templates, sondern Beschränkungen der Sprache "Java", und des dazugehörigen Runtime Supports. Ich werde den falschen und irreführenden Kommentar daher entfernen. [[Benutzer:Aragorn2|Aragorn2]] 21:13, 26. Mär 2005 (CET)

::Nochmal zur Klarheit: Im ersten Fall besitzt eine Template-Klasse eine virtuelle Methode. Das ist in C++ vollkommen zulässig. Im zweiten Fall besitzt eine Klasse (Template oder nicht) eine Schar von Methoden die über ein geschachteltes Template parameterisiert ist. Diese Methodenschar darf laut C++-Standard nicht "virtual" sein. Dieser Fall ist etwas völlig anderes als der erste, und ist mit Java nicht vergleichbar, weil es in Java zwar generische "Klassenscharen" gibt, aber keine "Funktionsscharen".
::Zulässig ist es in C++ jedoch nachwievor, Klassen mit Scharen nicht-virtueller Methoden zu versehen, Beispiel:

 template<class Encapsulated> class Encapsulate {
 private:
     Encapsulated m_object;
 
 public:
     template<class ConvertTo>
     operator ConvertTo() const {  // ok: Schar nicht-virtueller Methoden
         return m_object;
     }
 };

::Zu diesen dürfen auch wie üblich teilweise und vollständige Spezialisierungen angegeben werden. Eine derartige Funktionalität existiert in Java 5.0 nicht. [[Benutzer:Aragorn2|Aragorn2]] 23:58, 26. Mär 2005 (CET)

== Abschnitt Covarianz ==

Laut des Buches "Java ist auch eines Insel" gilt die genannte Vererbung im Abschnitt Covarianz nicht. Vielleicht verstehe ich hier auch etwas falsch, aber es liest sich im Artikel so, als würde aus 
'''T extends V''' 
automatisch 
'''Typ<T> extends Typ<V>''' 
folgen. Dies gilt jedoch nicht. In Java ist auch eine Insel steht:

"'''In Zusammenhang mit Generics und Vererbung muss beachtet werden, dass die übliche Substitution nicht funktioniert. Wenn Disko eine Unterklasse von Gebaeude ist, so ist Box<Disko> keine Unterklasse von Box<Gebaeude>, genauso wie Box<Object> nicht die Basisklasse von Box<Gebaeude> ist, beziehungsweise eine Box, die alle erdenklichen Typen ermöglicht.'''

Der Compiler meckert diesen Versuch sofort an.

Box<Object> box;
box = new Box<Disko>();      // incompatible types"

Siehe hierzu http://www.galileocomputing.de/openbook/javainsel4/javainsel_06_012.htm#Rxx365java06012040001D41F0321BE
Kapitel 6.13.3

== Dieser Artikel '''ist''' kein Artikel! ==

Hallo,

dieser Artikel erklärt zwar wunderbar in allen Facetten auch sehr freundlich für Java-Neulinge die Implentierung eines generischen Konzeptes in Java 1.5 ("Java 5.0"), aber irgendwie fehlt mir was an dem Artikel. Ja genau, es ist einfach so: Dieser Artikel ist kein [[Wikipedia:Artikel|Artikel]].

Laut [[Wikipedia:Wie_schreibe_ich_gute_Artikel#Aufbau_eines_Artikels]]: Ein Artikel braucht eine Einleitung. Der Begriff muss definiert werden. Bei diesem Artikel gibt es keinen Begriff, es gibt ein Thema. Der Artikel ist mehr ein wissenschaftlicher [[Aufsatz]] als ein Artikel.

In diesem Sinne: Ein hervorragender Beitrag, allerdings in der falschen Wiki. Ich finde, er wäre *deutlich* besser in [[Wikibooks]] aufgehoben, irgendwo im Regal Informatik. Sicherlich kommt ihm dort nicht so viel Aufmerksamkeit wie hier zu, aber die paar Links, die draufzeigen, lassen sich schnell umbiegen. So frech, den gesamten Inhalt zu entfernen werde ich allerdings nicht sein. Viel eher werde ich warten und auf eine Stellungnahme oder eine Diskussion reagieren.

Viele Grüße, --[[Benutzer:Benji|Benji]] 23:42, 31. Aug 2006 (CEST)

: Meine Meinung. In Wikipedia hat sowas nichts zu suchen -- [[Benutzer:84.167.196.85|84.167.196.85]] 15:56, 4. Okt. 2007 (CEST)
: sign, me too. Sonst kommt noch [[Fehlerbehandlung in Java 5.2]] oder [[Grüne Fenster in Java 3.4-3.9]] (Versionsnummern sind natürlich nur Beispiele *g*) --[[Benutzer:E7|E7]] 19:33, 4. Okt. 2007 (CEST)

::Ich habe auf [[wikibooks:de:Java:Fast ToDo]] mal rumgefragt, ob jemand Interesse an dem Artikel hätte. Ich würde ihn dann zu Wikibooks rüberschieben. --[[Benutzer:Benji|Benji]] 20:31, 8. Sep. 2008 (CEST)

== Beim praktischen Beispiel fehlt die Hälfte ==
Dass in dem Artikel ein praktisches Beispiel vorkommt, ist schonmal sehr gut und veranschaulicht die Sache. Dass danach die Varianzfälle beschrieben werden ist auch sinnvoll, nur ist nach meinem Geschmack ein praktisches Beispiel einer Klasse mit Genererics selbst ( zB. public class SingleObject<T> {... ) wichtiger als die Varianzfälle. Denn so fehlt genau genommen der Kern des Artikels (auf der Beispielebene betrachtet). Ich möchte also eine Entwicklung des Artikels in diese Richtung anregen, werde mich aber demnächst auch selbst drum kümmern. [[Benutzer:Christoph May|Christoph May]] 21:51, 20. Okt. 2008 (CEST)

So, is erledigt. [[Benutzer:Christoph May|Christoph May]] 11:22, 1. Dez. 2008 (CET)

== Polymorphie der Typparameter: Nicht ganz korrekt ==

Du hast geschrieben: "und das, obwohl Integer von Number abgeleitet ist. Der Grund liegt darin, dass der Compiler hier nicht mehr sicherstellen kann, dass keine Typfehler auftreten. Mit Arrays, die eine solche Zuweisung erlauben, hat man schlechte Erfahrungen gemacht:"

Richtig ist:
Es ist nicht so, dass man mit Arrays im Bezug auf die Polymorphie der Typparameter schlechte Erfahrungen gemacht hat. Vielmehr bleiben die Datentypen der Arrays auch nach dem Compilieren erhalten. Das bedeutet, nicht nur der Compiler kann Zuweisungen überprüfen, sondern auch die VM und zwar über die wirklichen Objekte im Heap. Es gibt somit bei den Arrays eine zweistufige Prüfung, welche die Datenintegrität des Arrays sicherstellt.
Die generischen Datentypen demgegenüber sind nur zur Kompilierzeit bekannt und werden danach gelöscht ('type erasure'), damit auch alter Java-Code uneingeschränkt weiterläuft. Hier kann die VM keine Prüfung mehr vornehmen. In Ermangelung einer zweiten Prüfung durch die VM wurde bei der Entwicklung der generischen Datentypen die Polymorphie der Typparameter nicht implementiert.

== Quellen für die Varianzen? ==

Eigentlich ist dieser Artikel eine nette Beschreibung von Java's Generics. Eines machte mich jedoch stutzig: Für die "Varianz-Formen" unter 3.1 (Invarianz, Kovarianz, Kontravarianz und Bivarianz) fand ich kaum oder keine Quellen. ich habe das halbe Netz durchsucht und auch in allen ACM- und IEEE-Artikeln recherchiert. Auf der englischen Variante des Artikels ist ebenfalls nichts zu finden.

Quellenangaben wären hier absolut angebracht!

Falls jemand Quellen kann, wäre ich für eine Benachrichtigung dankbar. :) <small>(''nicht [[Hilfe:Signatur|signierter]] Beitrag von'' [[Benutzer:Daniel L.F.|Daniel L.F.]] ([[Benutzer Diskussion:Daniel L.F.|Diskussion]]&nbsp;|&nbsp;[[Spezial:Beiträge/Daniel L.F.|Beiträge]]) 15:33, 30. Sep. 2009 (CEST)) </small>

== {{Anker|deadurl_2015-10}} Defekter Weblink ==
{{nicht archivieren|Zeigen=nein}}{{Defekter Weblink|Bot=GiftBot|Lauf=2015-10
|1=500 wba=20141127112006 http://www.theserverside.de/java-generics-generische-methoden-klassen-und-interfaces/
}}
– [[Benutzer:GiftBot|GiftBot]] ([[Benutzer Diskussion:GiftBot|Diskussion]]) 15:34, 4. Dez. 2015 (CET)

== Was hier m.M. völlig fehlt ==

Type erasure. Generics kapiert man erst richtig wenn man weiss wie und warum die unter der Haube so funktionieren wie sie eben in Java funktionieren.

Als Einführung des Artikels könnte man man den ganzen C++ spezifischen Quark rauswerfen, der hat in dem Artikel nix verloren und sich mal die Historie
von hier https://cr.openjdk.java.net/~briangoetz/valhalla/erasure.html in gekürzter Form übernehmen. Das halte ich für wichtiger als die C++-Spezialfälle abzuhandeln mit Templatemetaprgramming und der ganze Mist, was soll das in diesem Artikel? Wer das wissen will schaut unter C++ nach. Wenn der C++-Quark relevant wäre müsste man auch noch die Generics von zig anderen Sprachen aufführen.

Die Formulierungen und Aufbau der Beispiele sollte man auch nochmal überarbeiten und sauber vereinheitlichen. Bsp + Allgemeine Form oder umgekehrt. Solche Sätze wie " (im Beispiel von ? super Double ist T Double). Deshalb kann aus den obigen Listen nicht gelesen werden:" sind ungelenk, die allgemeine Def mit Pfeil wie die Abschnitte davor auch gehört dort hin oder am Anfang jedes xVarianz-Falles. {{unsigniert|2001:16B8:3170:6300:3774:864:9BC9:A5F0|21:21, 19. Sep. 2020 (CEST)}}