Sun, Microsoft und Java: Ansichten eines Insiders

ZDNet: Aber auch bei Java haben Unternehmen wie BEA Systems spezielle Funktionen hinzugefügt, die nur verfügbar sind, wenn die Software auf deren Java-Anwendungsservern ausgeführt wird. Java-Code ist also doch nicht zu 100 Prozent portabel.

Gosling: Ja, das ist ein Problem. Aber wenigstens ist es bislang in allen solchen Fällen so gewesen, dass diese speziellen Funktionen auch wirklich Sonderfunktionen sind. Es gibt eine Vereinbarung bei Java in Bezug auf die Benennung von Packages. Wenn man eine API benutzt (Application Programming Interface), muss man ausdrücklich eine öffentliche Standard API verwenden – java.irgendwas – oder man verwendet eine der proprietären APIs des Unternehmens – com.bea.irgendwas. Man ist als Entwickler gezwungen, ausdrücklich Rechenschaft zu geben. Die Entwickler machen sich wirklich über Portabilität Gedanken. Jedes Mal, wenn sie com.bea schreiben müssen, sitzt ihnen das schlechte Gewissen im Nacken. Eines der Probleme in der Javascript-Welt ist, dass man nie wirklich weiß, ob man eine Funktion benutzt, die nur mit einem bestimmten Browser funktioniert.

Und so, wie sich die Dinge inzwischen entwickelt haben, hat man seinen Anbieter für Anwendungsserver, der mit irgendeiner Idee aufwartet, die alle für gut befinden, und häufig wird daraus ein JSR (Java Specification Request). Die zweite oder dritte Version des Unternehmens hiervon wäre dann schon Bestandteil des Standard-Java-Frameworks.

ZDNet: Könnten Sie nicht Java als Open-Source-Software freigeben und die Kompatibilität mithilfe von Branding sicherstellen? Sie könnten verlangen, dass Software zertifiziert wird, ehe sie den Namen Java verwenden darf.

Gosling: Darüber haben wir schon ausgiebig diskutiert. Sun ist eine Demokratie – einige glauben, dass dies funktionieren würde, einige nicht. Im Moment haben die Skeptiker die Überhand.

ZDNet: Zählen Sie auch eher zu den Skeptikern?

Gosling: Nein, eigentlich bin ich eher auf der Seite der Befürworter. Aber ich muss zugeben, dass ich da manchmal auch am schwanken bin.

ZDNet: Wie unterscheidet sich die Arbeit an Java heute von der Zeit vor fünf Jahren?

Gosling: Der große Unterschied zwischen den letzten fünf Jahren und den ersten fünf Jahren besteht darin, dass Java inzwischen Bestandteil vieler riesiger, unternehmenskritischer Systeme geworden ist. Das verlangt einen geradezu paranoiden Konservatismus. Stellen Sie sich eine große Bank vor, die jede Nacht Hunderte von Milliarden von Finanztransaktionen durchführt – da haben selbst kleinste Fehler enorme Folgen. Am Anfang konnten wir noch alle möglichen verrückten Sachen ausprobieren, aber inzwischen müssen wir uns gründlich überlegen, auf wen das alles Auswirkungen hat. Jeder Bug, den wir beheben, verursacht Probleme für jemanden, der sich einen provisorischen Workaround zusammengezimmert hat. Das Ganze verlangt eine äußerst akribische Herangehensweise.

ZDNet: Durch Projekte wie Groovy verspricht Sun, die Welten von Java und Skriptsprachen dichter zusammen zu rücken. Ich muss allerdings gestehen, dass mir der genaue Unterschied zwischen Programmiersprachen und Skriptsprachen wie PHP, Perl oder Python nicht ganz klar ist.

Gosling: Ihre Verwirrung kann ich gut verstehen. Da wird sprachlich auch nicht immer genau unterschieden. Die Begriffe bedeuten jedem etwas anderes.

Wenn die Leute von Skriptsprachen sprechen, dann meinen sie damit oft, dass der Entwickler ganz schnell etwas zusammenbastelt um innerhalb weniger Minuten eine Demoversion zu erstellen. Wie schnell das Programm ist, wie gut es skalierbar ist oder wie große Systeme man damit erstellen kann, sind eher nachrangige Überlegungen. Beim Design von Java machten wir uns weniger darum Gedanken, wie schnell man eine Demoversion fertig stellen kann, sondern vielmehr darüber, wie schnell wir ein umfangreiches, skalierbares System fertig stellen konnten. Das führte zu schwierigen Entscheidungen. Im Allgemeinen sind Skriptsprachen viel einfacher zu entwerfen als die „echten“ Programmiersprachen.

Das Java-Design umfasst zwei Ebenen: die Java Virtual Machine und die Programmiersprache Java. Alle schwierigen Sachen finden sich auf der Ebene der JVM oder darunter. Falls man eine Skriptsprache entwickeln würde, die an die JVM andockt, könnte man die Vorteile beider Ansätze nutzen.

ZDNet: Sie führen also Skriptcode in einer JVM aus?

Gosling: Ja. Alle Java-Bibliotheken sind für Code zugänglich, der in Groovy geschrieben ist. Und Java-Anwendungen können Groovy verwenden. Sie können Groovy-Scriptlets enthalten.

ZDNet: Danke für das Gespräch.