Manager sagt, warum Java in Händen von Sun bleibt

Die Plattform fuße schließlich auf einer Struktur, die Kompatibilität geradezu garantiere. Die Unvereinbarkeit mit anderen Softwarewelten müsse dabei gar nicht absichtlich entstehen, sie könne auch ein Nebenprodukt sein, das ohne böse Absicht entstehe. Ungefährlicher sei das aber nicht.

Wie Simon Phipps, Chief Open Source Architect von Sun, am Rande der JavaOne Anfang Mai gegenüber der US-Presse sagte, soll die Kompatibilität weiterhin durch Sun garantiert werden. Er glaube zwar nicht, dass irgendjemand absichtlich die Benutzbarkeit von Java zerstören wolle, die dadurch gegeben sei. Doch die Marktmacht einiger Lizenznehmer von Java macht ihn offenbar nachdenklich. Durch die Entwicklung eigener vertikaler Lösungen könnten diese – mit oder ohne Absicht – Javas Anwendungsfreundlichkeit brechen.

Namentlich nannte er Sun selbst, IBM oder Nokia. Sie könnten eine Verschiebung der Kompatibilität und damit des Java-Gedankens an sich und der Einsetzbarkeit gefährden. Dabei könne der Bruch der Kompatibilität auch im Verborgenen geschehen und sich erst viel später als Auslöser einer grundlegenden Veränderung in Java herausstellen. So könne eine neue Funktion gebaut werden, deren Grundlage eben nicht ganz reines Java sei, die aber im Markt auf Akzeptanz stoßen könne und weiter entwickelt werde – mit dieser unreinen Java-Basis.

Die Java-Wächter, so sagte er, müssten daher sehr wachsam sein – und die Kontrolle, die Sun über den Java-Code ausüben will, weiter unterstützen. Schließlich könne eine Entwicklung solchen Auftrieb im Markt bekommen, dass diese Anwendung und nicht mehr die Reinheit der zugrunde liegenden Technik – sprich Java – im Mittelpunkt stehe.

Auch die schiere Marktmacht eines Herstellers könne eine schnelle Massenakzeptanz einer solchen Technik nach sich ziehen. Im Ergebnis könne eine Verwässerung des Codes ungeahnte Folgen für die gesamte Java-Landschaft haben. Er rief die Mitglieder des Java Community Process auf, als Verteidiger von Java wachsam zu sein und solche Entwicklungen zu stoppen.

Java solle lieber kontrolliert, hundert Prozent rein und damit kompatibel bleiben, sagte der Open Source Officer, der auf der CeBIT 2006 die Vorteile von Open Source beschwor. In diesem Punkt ist er aber unerbittlich. Java Open Source zu machen hieße sehr wohl, dass jeder den Code sehen, nutzen und verändern könne. Daher sei eine Öffnung von Java in bestimmten Punkten denkbar – jedoch nicht an einer Stelle, die zu Inkompatibilitäten führen könne, zitiert ihn die US-Presse.

Die nicht so tief verwurzelten Bereiche von Java, die offengelegt werden können, werden demnach einfacher und schneller geöffnet als dies bei Solaris der Fall war, sagte er. Eine Öffnung in dieser Richtung ist ihm zufolge in Java selbst angelegt. Der Prozess werde schnell und schrittweise passieren. Und natürlich unter fester Kontrolle von Sun.

Nur so bleibe gewährleistet, das Java nicht nur abhängig von der Marktpräsenz eines Unternehmens eingesetzt werde, sondern jedermann nützlich sei. Die Frage sei also nicht ob oder wann Java Open Source gemacht werde, sondern wie und was hiervon. Und darüber will sich Sun die Kontrolle nicht aus der Hand nehmen lassen. Dafür scheint auch der neue CEO Jonathan Schwartz zunächst ein Garant zu sein. Phipps ist sich dem Bericht zufolge in diesem Punkt mit seinem Chef einig.