CW: Java ist jetzt Open Source, obwohl Sun sich lange Zeit dagegen ausgesprochen hat. Warum hat man sich schließlich doch für die Freigabe von Java entschieden?

GOSLING: Der Source Code von Java ist ja bereits seit der Freigabe von Java vor über zwölf Jahren verfügbar. Und auch die Community wurde von Anfang an sehr stark eingebunden. Das heißt, eigentlich waren wir schon immer ein Open-Source-Projekt. Entscheidend neu ist eigentlich nur, dass wir Java jetzt unter die GPL V2 gestellt haben. Viele sehen darin eine große Veränderung, für uns hat sich dadurch nichts verändert.

CW: Java ist mittlerweile enorm komplex. Entsprechend große Open-Source-Projekte existieren oftmals nur, weil ein kommerzielles Unternehmen dahinter steht. Erwarten Sie, dass die Java Community Entscheidendes zur Weiterentwicklung von Java beitragen wird?

GOSLING: Open-Source-Projekte brauchen entweder ein kommerzielles Geschäftsmodell oder ein kommerzielles Unternehmen, das hinter dem Projekt steht, um funktionieren zu können. Wie Sie wissen, ist Sun die treibende Kraft hinter Java. Aber auch viele andere Unternehmen sind in den Entwicklungsprozess eingebunden, darunter IBM und Bea. Ein wichtiger Beitrag, den die Community in der Vergangenheit geleistet hat und den wir auch in Zukunft erwarten, ist Testen und Bugfixing. Wir legen sehr großen Wert auf konstante Qualität und arbeiten deshalb mit der Community an Konzepten, die Testmechanismen und Qualitätssicherung zum festen Bestandteil der Entwicklung machen.

CW: Sie haben IBM angesprochen. Besteht die Gefahr, dass Sun die Kontrolle über Java verlieren könnte?

GOSLING: Wir haben die Kontrolle über Java bereits vor Jahren komplett an die Community abgegeben. Auch wenn wir sicher am meisten zu Java beisteuern. Unsere Sorge besteht jedoch nicht darin, die Kontrolle über Java zu verlieren, sondern darin, dass die Kompatibilität von Java verloren gehen könnte. Was sich in den vergangenen Jahren allerdings verändert hat, ist, dass die Community selbst großen Wert auf die Kompatibilität legt und nun sehr darauf achtet, dass die Plattformunabhängigkeit gewahrt bleibt.

CW: Heute lesen wir, dass Java als Sprache für das Web entwickelt wurde. Warum sieht man heutzutage immer weniger Applets im Internet?

GOSLING: Applets werden in der Praxis tatsächlich viel weniger genutzt als es eigentlich möglich wäre. Das liegt vermutlich daran, dass alternativ auch das Java Network Launching Protocol (JNLP - Java Webstart) eingesetzt werden kann. JNLP ermöglicht Desktop-Applikationen den Zugriff auf das Web. Viele Anwender setzen bei Enterprise-Applikationen mittlerweile auf diese Technik. Zudem fehlen immer noch Tools, die Applets generieren. Dennoch ist der Einsatz von Java-Applets eine effektive Möglichkeit, leistungsvolle Web-Anwendungen zu entwickeln.

CW: Das .NET-Framework profitiert stark von den zahlreichen Visual-Basic-Entwicklern. Wie sehr wird sich Java für andere Sprachen öffnen, um noch mehr Verbreitung zu finden?

GOSLING: Die Java Runtime unterstützt ja bereits viele Sprachen, und auch die Compiler dafür sind erhältlich. So gibt es Implementierungen für Python und Ruby, welche die Java Virtual Machine (VM) nutzen und nebenbei eine erstaunliche Performance bieten. Mit JavaFX Script haben wir jetzt eine neue Skriptsprache angekündigt, die auf die Oberflächenentwicklung abzielt. Die Java-Plattform bietet interessante Möglichkeiten für Interoperatibilität zwischen allen möglichen Skriptsprachen. Java selbst ist besonders für Enterprise-Lösungen geeignet. Diese lassen sich jetzt sehr leicht mit Skriptsprachen zusammenführen. Alle Skriptsprachen, die auf der VM laufen, habe Zugriff auf sämtliche APIs und können zudem gegenseitig aufeinander zugreifen. So lassen sich zum Beispiel Ruby und Python gleichzeitig in einer Anwendung verwenden.

CW: Es gilt als offenes Geheimnis, dass Microsoft bei der Entwicklung von C# sehr viel von Java abgeschaut hat. Was haben Ihrer Meinung nach die Entwickler von C# trotzdem falsch gemacht?

GOSLING: Bei der Entwicklung von C# wurde ein Großteil der Java-Spezifikationen schlicht und einfach nur kopiert. An der Plattformunabhängigkeit wurde jedoch völlig vorbei entwickelt, genauso wie man wenig Wert auf die Sicherheitsaspekte gelegt hat. Die gesamte Pointer-Problematik wurde aus C und C++ übernommen, um zu diesen Sprachen kompatibel zu sein. Das heißt, es wurden alle Altlasten dieser Sprachen übernommen, was eine entscheidende Sicherheitslücke darstellt. Zuverlässigkeit und Sicherheit sind sehr kritische Themen, auf die wir sehr großen Wert gelegt haben.

CW: Gibt es auch an Java etwas, das Sie ändern würden, wenn Sie noch einmal zehn Jahre zurückgehen könnten?

GOSLING: Das ist schwer zu sagen. Natürlich gibt es Dinge, die wir gerne schon viel früher umgesetzt hätten, wie zum Beispiel die Generics. Auch in der Vergangenheit wurde bereits heftig über Features diskutiert. Sicher wäre es optimal, alles bereits in der ersten Version haben zu können. Aber damals wie heute ist Entwicklung immer ein Kompromiss zwischen Funktionsumfang und zeitlicher Machbarkeit. Letztlich bin ich der Meinung, dass wir einen guten Job gemacht haben.

CW: Die Entwicklung und Verbreitung von mobilen Java-Anwendungen wird in der Praxis durch die Gerätehersteller sehr erschwert. Ist hier eine Verbesserung in Sicht?

GOSLING: Das ist tatsächlich ein Bereich, der uns Sorgen bereitet. Für diese Situation gibt es allerdings auch zahlreiche historisch bedingte Gründe. Vor etwa sechs Jahren waren die Geräte noch sehr primitiv. Die Hersteller waren bereit, auch unorthodoxe Wege zu gehen, um Java zu unterstützen. Heutzutage besitzen die Geräte ausreichend Rechenleistung, so dass sich die Hersteller etwas mehr Kompatibilität leisten können. Wir arbeiten mit allen Herstellern sehr intensiv zusammen, um die Situation zu verbessern. Vor kurzem wurde dazu die Initiative MSA gegründet, die eine Sammlung von APIs definiert, die überall funktionieren und somit für Standards sorgen sollen. Darüber hinaus gewichten wir nun auch die Binärversion unserer VM stärker. Bisher hat Sun keine fertig kompilierte Versionen für die Hersteller herausgegeben, so dass diese ihre eigenen Java VM entwickelt oder unsere VM angepasst haben. Dafür gab es nie eine wirkliche Kompatibilitäts-Prüfung. Wir planen nun eine IBM-Technik einzusetzen und bieten Herstellern standardisierte Binärversionen unserer VM an, wodurch wir uns mehr Kontrolle über den Qualitätssicherungsprozess erwarten.

CW: Die Freigabe von Java 6 ist noch nicht lange her. Aber wir sind jetzt schon neugierig, was uns Java 7 bringen wird?

GOSLING: Die Annahmephase von Java 6 beginnt ja gerade erst und wir sind damit sehr zufrieden. Für Java 7 existiert bereits eine lange Wunschliste an Features. Darin enthalten sind unter anderem eine Vielzahl von Sprachänderungen. Eine der intensivsten Diskussionen wird gerade über die "Closures"-Technik geführt, von der ich mir wünschen würde, dass sie mit aufgenommen wird. Einige Dinge im Bereich Packaging werden ebenso besprochen. Hier geht es darum, Komponenten modularer, auf einander aufbauend downloadbar und dadurch flexibler zu machen. Zudem wollen wir uns noch mit der Benutzerfreundlichkeit beschäftigen und versuchen eventuell auch die 3D-API mit einzubeziehen. Darüber hinaus stehen viele weitere Punkte auf der Liste. Allerdings ist es noch viel zu früh, um Konkreteres sagen zu können.

CW: Wenn wir in die Zukunft blicken, wird man dann in zehn bis 20 Jahren immer noch objektorientiert entwickeln, oder sehen Sie bereits andere Konzepte auf uns zukommen?

GOSLING: Für die nächsten zehn Jahre wird OOP auch weiterhin Mainstream sein. Es ist ziemlich schwer vorherzusagen, wodurch sich das ändern könnte. Das OO-Framework gibt es seit über 40 Jahren, und es hat seine Mächtigkeit zweifellos unter Beweis gestellt. Was sich in einem Zeitraum von 20 Jahren ändern könnte, ist unsere Denkweise über Multithreading. Jedoch liegt hier noch eine Menge Forschungsarbeit vor uns. (ue)