Zusammenfassung
Übersicht: Zusammenfassung
Eigenschaften
Hier noch einmal eine kurze Zusammenfassung:
- Kompatibilität mit der Java Programmiersprache: Jedes Java Programm ist weiterhin gültig und behält seine Bedeutung. Das gilt für alten Source Code und für JVM Class Dateien.
- Kompatibilität mit JVM: GJ wird in normalen Bytecode Code übersetzt. Es ist keine Änderung an der JVM nötig. Der endgültige Entwurf sieht jedoch eine Änderung vor, die aber mit dem Reflecion-API zu tun hat.
- Kompatibilität zu existierenden Bibliotheken: Ein Programm, dass mit parametrisierten Typen kompiliert wird, kann mit existierenden Bibliotheken (die keine Generizität kennen) benutzt werden
- Transparente Übersetzung: die Übersetzung in die Java Programmiersprache lässt Felder und Methodennamen unverändert. Es werden teilweise Brückenmethoden eingeführt, deren Erzeugung leicht vorherzusehen ist.
- Effizienz: GJ wird übersetzt, indem die Typinformation gelöscht wird. Keine parametrische Typinformation ist zur Laufzeit verfügbar. Der Code ist beinahe äquivalent zu Java Code der ohne Generizität arbeitet (d.h. auch genauso schnell bzw. langsam)
- Zukunftssicher: es wird nicht ausgeschlossen das Konzept später um Laufzeit-Typinformationen zu erweitern. Eine derartige Erweiterung ist möglich.
Kommentare
Eigentlich hätte für diese Erweiterungen auch die JVM nicht geändert werden müssen. In der letzten Veröffentlichung von Sun wird aber eine Veränderung angekündigt, die es erlauben soll das Reflection-API im Zusammenhang mit generischem Code zu verwenden. Wirkliche "Typinformation zur Laufzeit" erhält man damit aber nicht. Auf diesen Punkt wird hier nicht weiter eingegangen.
Generizität in Java erlaubt alles, was man üblicherweise mit Typparametrisierung in Verbindung bringt. Die Implementierung von Generizität in C++, mit dem Template Konzept, erlaubt darüber hinaus aber Programmiertechniken die mit Java niemals erreicht werden können. Dazu muss man nur kurz in "Modern C++ Design: Generic Programming and Design Patterns Applied" [
Alexandrescu2001] rein sehen. Unter anderem können in C++ Templates spezialisiert werden, so dass für bestimmte Typen nicht die allgemeine, sondern eine spezielle Implementierung genutzt wird. Haskell verfügt mit Typklassen über ein ähnliches Konzept. In Java ist so etwas nicht umsetzbar. Templates sind äußerst mächtig und erlauben sogar eine Art von Metaprogrammierung, die zur Compilezeit aufgelöst wird. Es ist wohl Geschmackssache, ob man diese Mächtigkeit schätzt oder die Komplexität kritisiert.
Alles in allem scheint der Entwurf für Java unter Berücksichtigung der Probleme, die eine solche Erweiterung für eine existierende Sprache bringen kann, die beste Lösung zu sein. Die hohe Kompatibilität und doch recht einfache Umsetzung dürfte dieser Lösung den Vorrang vor anderen Vorschlägen gegeben haben. Man muss die generische Funktionalität nicht nutzen, aber man kann es. Einem langsamen "upgrade" auf generischen Code steht damit nichts im Wege. Besser wäre es natürlich gewesen, Sun hätte Java gleich mit entsprechen Möglichkeiten ausgestattet, anstatt die Sprache Stück für Stück zu erweitern. In den Diskussionsforen von Sun wird schon das Thema Operatorüberladung diskutiert...
Schlussbemerkung
Es ist denkbar, dass Java irgendwann mit parametrischen Typen ausgestattet wird, die zur Laufzeit verfügbar bleiben. Der NextGen Vorschlag [
Cartwright98] wäre hierfür wohl das wahrscheinlichste Konzept, denn jedes Javaprogramm in GJ ist auch ein gültiges NextGen-Programm. NextGen ist auch abwärtskompatibel und erfordert fast keine JVM-Änderungen. Allerdings ist es schwieriger alten mit neuem Code zu mischen, so dass ein Umstieg auf NextGen mehr Anpassungen nötig macht, als ein Umstieg von Java 1.4 auf 1.5. Die Umsetzung basiert in vielen Punkten auf GJ, zur Beibehaltung der Typinformation werden aber für jede "Typinstanziierung" Wrapper-Klasse erzeugt. Diese leiteten Methodenaufrufe weiter, es kommt also nicht zu der vollständigen Codeverdopplung wie in C++. Besser wäre es aber, die JVM und der ByteCode würden soweit geändert, dass generische Typ-Information im ByteCode stehen kann. Noch ist offen, ob Sun diesen Schritt irgendwann gehen wird. Vielleicht in einem nicht mehr abwärtskompatiblen Java3?
C++ hatte anfangs auch keine Generizität. Bertrand Meyer sagte dazu [
Meyer98]:
"Correction these early oversights in C++ was a long and painful process, creating years of havoc as compilers never quite supported the same language, books never quite gave accurate information, trainers never quite taught the right stuff, and programmers never quite knew what to think."
Es bleibt nur zu hoffen, dass Sun die bestehenden Unklarheiten bald beseitigen wird und Java nicht das gleiche passiert wie C++! Die derzeitige Situation ist jedenfalls nicht befriedigend.
Code generated with AusarbeitungGenerator Version 1.1, weblink