GOSLING: Wir hatten für die Entwicklung von AWT vier Wochen Zeit, bevor Java 1.0 ausgeliefert wurde. Angesichts dieser Umstände finde ich das AWT eigentlich ganz gut. Es gibt viele Leute, die AWT samt seinem problematischen Event-Modell liebend gerne aus Java löschen würden - und ich gehöre ganz vorne mit dazu. Wir haben mittlerweile einige Altlasten in Java, von deren Verwendung wir schon länger abraten. Aber wir können sie aus Gründen der Abwärtskompatibilität nicht einfach eliminieren.

CW: Möglicherweise etabliert sich in Java bald eine dritte Grafikbibliothek. Ich spreche von IBMs „Standard Widget Toolkit“ (SWT), das mit „Eclipse“ ausgeliefert wird. SWT nutzt die nativen Dialoge des Betriebssystems und soll laut IBM daher schneller ablaufen als Swing. Außerdem sähen Java-Anwendungen dann so aus wie native Programme für das jeweilige System. Wie denken Sie über dieses Modell?

GOSLING: Das ist absolut lächerlich. SWT verfolgt doch den gleichen Ansatz wie AWT! Genau das Betriebssystem-abhängige Look and Feel empfanden viele Anwender als Nachteil, weil es ihnen Schwierigkeiten beim Verfassen der Dokumentation bereitete. Swing hingegen bietet mehrere Oberflächen zur Auswahl, die sich über alle Betriebssysteme hinweg exakt gleich verhalten. Sobald Sie nach dem Muster von IBM mehrere Plattformen unterstützen wollen, geraten Sie in Teufels Küche.

Wenn ein bestimmtes Bildschirmelement, das Sie sonst überall anbieten möchten, auf einigen Systemen nicht existiert, müssen Sie es dort in Java nachbauen. Zum Schluss haben Sie dann ein riesiges Set selbst entworfener Komponenten à la Swing und müssen zudem die ganze Komplexität der Betriebssystem-eigenen Dialoge beherrschen. Besonders unverständlich finde ich, dass ausgerechnet die IBM einen solchen Vorstoß unternimmt. Diese Firma hat uns am meisten dazu gedrängt, Swing zu entwickeln.

CW: Seit Microsoft .NET vorstellte, fordern Beobachter immer wieder, dass auch die Java-Plattform mehrsprachig werden müsse. Zwar lassen sich diverse Programmiersprachen für die Java Virtual Machine (JVM) übersetzen, den Segen von Sun gab es dafür aber nie. Planen Sie eine „offizielle“ Mehrsprachigkeit von Java, etwa durch Zertifizierungen?

GOSLING: Tatsächlich existieren schon seit längerem Compiler für unterschiedliche Programmiersprachen, die Java-Bytecode erzeugen können. Aus unserer Sicht ist das völlig in Ordnung. Allerdings sehe ich nicht, welchen Nutzen eine Zertifizierung solcher Übersetzer haben soll. Wir selbst konnten keine nennenswerte Nachfrage nach anderen Sprachen feststellen.

Auch wenn sich die meisten Sprachen gut mit der JVM vertragen, so gibt es aufgrund ihres übergreifenden Objekt- und Speichermodells doch häufig subtile Probleme. Besonders gilt dies für C und C++, die den Konzepten von Java hinsichtlich Sicherheit und Verlässlichkeit widersprechen. Wir könnten beide Sprachen unterstützen, aber nur auf Kosten dieser Eigenschaften.

Microsoft stand im Prinzip vor der gleichen Situation wie wir. Zum einen müssen Sprachen an das allgemein gültige Objektmodell der Common Language Runtime (CLR) angepasst werden. Besuchen Sie doch die Website von Eiffel und beachten Sie den Unterschied zwischen „richtigem“ Eiffel und Eiffel für .NET. Das sind verschiedene Sprachen. Ähnliches gilt auch für C++, da kann bestehender Code nicht einfach übernommen werden. Wenn Microsoft behauptet, .NET unterstütze mehrere Sprachen, dann ist das eigentlich falsch.

Zum anderen hat Microsoft mit C/C++ für .NET die wesentlichen Vorteile einer Laufzeitumgebung eliminiert. Weil die Verwendung von Zeigern weiterhin erlaubt ist, schleppt man die altbekannten Probleme dieser Sprachen auch in Zukunft mit. Dazu zählen besonders ungültige Speicherzugriffe, die oft nur schwer auffindbar sind und die Entwicklungszeit verlängern. Vor allem stellen sie aber ein riesiges Sicherheitsproblem dar. Merkwürdig finde ich außerdem, dass nicht nur diese Legacy-Sprachen Risiken bergen, sondern dass auch C# mit seinem „unsafe mode“ das Speichermodell der CLR aushebelt.