Es ist schwer zu entscheiden, ob das wichtigste Ereignis der New Yorker Fachmesse Java Business Expo die weitgehend kostenlose Freigabe des Java-Quellcodes war oder die gleichzeitige Ankündigung der Version 1.2 des Java Developer Kits unter der Bezeichnung "Java 2" (siehe Kasten). Geht es bei dem neuen Entwicklerpaket vor allem um eine Fülle von Funktionen, mit denen sich Java in der Unternehmens-DV auf Server-Ebene etablieren soll, so handelt es sich bei der Offenlegung des Sourcecodes um ein Branchenpolitikum ersten Rangs.
Immer wieder wurde und wird Sun von Partnern wie Gegnern gedrängt, die Kontrolle über Java an herstellerübergreifende Gremien, konkret die International Organization for Standardization (ISO), abzutreten. Da es sich bei Java weniger um ein Produkt als vielmehr um eine Infrastruktur für plattformunabhängige Datenverarbeitung handle, müsse sie der gesamten Industrie gleichberechtigt zur Verfügung stehen.
Anders als andere Firmen tut sich Sun schwer, auf sein geistiges Eigentum und die Notwendigkeit zu pochen, mit einem Produkt wie Java Geld zu erwirtschaften. Zu oft hat das Unternehmen Microsoft mit dem Infrastruktur-Argument aufgefordert, seine Windows-Technik offenzulegen und die Weiterentwicklung des Betriebssystems einem unabhängigen Gremium zu überlassen. Proprietäres Vorgehen würde Sun unglaubwürdig machen. Hinzu kommt, daß mit der IBM der weitaus mächtigste Verbündete auf eine weitgehende Öffnung drängt.
Schon früh hat Sun daher mit der ISO kooperiert und nach einigem Zögern anderen Firmen ein Vorschlagsrecht bei der Mitwirkung an der Weiterentwicklung von Java eingeräumt - ohne allerdings seine Führungsrolle aufzugeben. Die Wirksamkeit dieser Strategie hat sich gerade erst bei dem Gerichtsverfahren gezeigt, in dem Sun Microsoft zur Einhaltung seiner Java-Lizenzverpflichtungen zwingen konnte.
Nun glaubt Sun, ein Lizenzmodell gefunden zu haben, mit dem ihm die Kontrolle nicht ganz entgleitet, der Ruf von Java als herstellerunabhängige Plattform aber trotzdem nicht beschädigt wird. So kann sich künftig jeder Interessent Java im Quellcode aus dem Internet laden und es beliebig verändern. Auch dürfen die Klassenbibliotheken von Java 2 mit den Java Virtual Machines anderer Hersteller gemischt und vermarktet werden. Lizenzgebühren an Sun werden nur fällig, wenn ein Produkt erstellt wird, das als kompiliertes Programm, also nicht im Quellcode, vermarktet werden soll. Hier behält sich Sun zudem das Recht vor, die Software auf Java-Kompatibilität zu prüfen. Auch Dienstleister, die auf Basis von Java-Sourcecode Geschäfte machen, müssen Lizenzgebühren entrichten. "Wir verdienen erst Geld, wenn Sie welches verdienen", versprach Suns Chief Operating Officer Ed Zander den Kunden bei der Vorstellung des Konzepts.
Von Vorteil ist das neue Lizenzverfahren vor allem für Anwenderunternehmen, die für eigene Zwecke entwickeln. Außerdem verschafft es Software-Unternehmen mehr Freiheit bei der Entwicklung von Java-Programmen für bestimmte Branchen oder andere von Sun nicht erkannte Einsatznischen. In Grenzen hält sich die Begeisterung bei Unternehmen wie Hewlett-Packard, die als Lizenznehmer für ihre Zwecke eigene Java-Derivate hergestellt haben. Diese im bisherigen Lizenzverfahren nicht vorgesehenen Clones können jetzt legalisiert werden, sofern sie Suns Kompatibilitätstests bestehen. Dafür aber muß der Hersteller aber Lizenznehmer werden und beim Verkauf der Software Gebühren an Sun abführen.
Die Open-Source-Anbieter kann Sun mit seinem Lizenzverfahren ebenfalls nur schwer gewinnen. Puristen aus dieser Szene wie der strategische Kopf Eric Raymond diskreditieren das Developer Kit als "pseudo-freies Java". Tatsächlich trifft gerade die Open-Source-Gemeinde die Regelung hart, wonach bei der Entstehung von kommerziellen Produkten Lizenzgebüren zu entrichten sind. Viele von ihnen leben davon, preisgünstige Lösungspakete zu verkaufen, die zu einem Großteil aus kostenloser Software bestehen. Da sich derartige Bündel nicht mit Produkten aus dem Umfeld von Microsofts Windows-Techniken schnüren lassen, setzen viele solche Softwerker bei der Anwendungsentwicklung auf Java. Auch aufgrund dieser Abhängigkeit glaubt Sun offenbar, daß diese Programmierer in der Hoffnung, lukrative Produkte zu erzeugen, trotzdem weiter auf Java vertrauen.
Auch Big Blue geht die Java-Öffnung noch nicht weit genug. Der Konzern ist in einem Maße auf Java-Kurs eingeschwenkt, daß ein Scheitern dieser Technik oder ein Sinneswandel bei Sun enorme Probleme verursachen würde. Bei der IBM gilt Java vor allem als Integrationsplattform unterschiedlichster DV-Techniken und als Überlebensgarantie für die von der IBM immer noch weitgehend kontrollierten Rechenzentren. Schließlich heißt Lean Client immer auch Fat Server.
Darüber hinaus setzt die IBM auch bei neuen Produkten auf Java. Dazu gehört neben Entwickler-Tools und Web-Applikations-Servern das Framework "San Francisco", das Softwarefirmen mit einer Ablaufumgebung und Halbfertig-Modulen für betriebswirtschaftliche Anwendungen ausstattet. Investitionen in solche Pakete sind immer langfristig, deshalb will die IBM sichergehen, daß sich die verwendeten Java-Basistechniken nicht ständig ändern. Das Unternehmen fordert daher einen breiten Satz an standardisierten Anwendungs-Programmier-Interfaces (APIs), die von einem herstellerübergreifenden Gremium, konkret der ISO, garantiert werden.
Gegen eine solche Normierung spricht, daß die dafür zuständigen Gremien erfahrungsgemäß weit langsamer arbeiten, als sich die Techniken entwickeln. Sun vertritt daher den Standpunkt, daß die ISO Java-Techniken zwar mittelfristig zertifizieren, die Etablierung von "De-facto-Standards" aber dem Markt überlassen bleiben soll. Gespannt wartet nun die IBM und mit ihr die gesamte Branche, welchen Vorschlag Sun Anfang kommenden Jahres zusammen mit dem neuen Java Developer Kit bei der ISO einreicht. Dabei geht es vor allem um den Grad der Beteiligung der Industrie an der Schnittstellen-Definition. "Ich neige dazu, nur solche Firmen zu beteiligen, die Lizenznehmer sind und konstruktiv mitarbeiten wollen", beschrieb Suns Chief Operation Officer Ed Zander seine Haltung.
Zu dieser Einstellung paßt, daß Sun einzelnen Partnern das Recht einräumt, die Entwicklung bestimmter Java-Ausprägungen zu leiten. Daß jedoch beispielsweise der IBM die Entwicklung einer Spezifikation für ein Echtzeit-Java übertragen wurde, ist durchaus als Seitenhieb gegen Hewlett-Packard zu verstehen. Der Hersteller hat nämlich schon längst ohne den Segen von Sun mit einer solchen Entwicklung begonnen. Trotz solcher Animositäten gibt sich Zander versöhnlich. Da Microsoft sich nun offensichtlich an die Lizenzbedingungen halte, sei auch dieses Unternehmen willkommen - auch wenn es schwerfalle, HP und Microsoft zuzuhören.
Java 2 für den Unternehmenseinsatz
"Java 2 ist stabil wie ein Felsen, schneller und vor allem für den Unternehmenseinsatz geeignet." Mit diesen Argumenten begründete Alan Baratz, President von Suns Java Platform Group, die Umbenennung des Java Developer Kit 1.2 in Java 2. Die Software läuft in der Einführungsphase unter Suns Solaris sowie unter Microsofts Windows-Betriebssystemen. Andere Unix-Derivate, darunter auch Linux, sowie Apples Mac-OS, Novells Netware und IBMs OS/2 folgen. Die Marktforscher von Dataquest heben die Eignung für die Unternehmens-DV hervor und vergleichen die Abfolge der drei Java-Versionen mit Kindheit (Version 1.0), Jugend (1.1) und der Reife eines Erwachsenen (Java 2).
Sicherheit: Java 2 verfügt über ein Konzept, das den Entwicklern erlaubt, den Anwendungen abgestufte Rechte zuzuweisen. Auf diese Weise wird das "Sandbox"-Verfahren durch Möglichkeiten erweitert, auf Ressourcen wie etwa Festplatten oder Server zuzugreifen.
Messaging: Die Entwickler erhalten Corba-Funktionalität inklusive aller Dienste etwa zur Einbindung von Unternehmensanwendungen.
Geschwindigkeit: Die Leistungsfähigkeit wurde unter anderem durch ein verbessertes Konzept für Speicherverwaltung (Garbage Collection) sowie durch die Integration eines Just-in-time-Compilers verbessert. Mit Hilfe des dynamischen Laufzeit-Compilers der Virtual Machine "Hotspot" soll Java 2 zudem um weitere 70 Prozent schneller werden.
Benutzeroberfläche: Das Developer Kit enthält "Swing"-Klassen, mit denen sich Oberflächen gestalten lassen, die dem Look and feel etwa am Mac- oder Windows-Arbeitsplatz angepaßt sind. Außerdem wurde ein eigenes Java-Look-and-feel entwickelt. Bislang galt dieser Bereich als eine der gravierendsten Schwachstellen von Java.
Grafik: Zweidimensionale Darstellungen sollen künftig auf allen Systemen in den richtigen Farben erscheinen. Außerdem gibt es Kommandos für die Manipulation von Bildern, Texten und Grafikwerkzeugen.
Drag and drop: Daten lassen sich nun per Mausklick innerhalb von Java-Anwendungen oder zwischen Java-Programmen verschieben.Hermann Gfaller hgfallercomputerwoche.de