"Sun führt sich wie ein Diktator auf, von dessen Wohlwollen es abhängt, ob Java in Zukunft proprietär wird oder nicht. IBM will hingegen einen formalen Standardisierungsprozess, der ihr legale Mittel in die Hand gibt, um Sun gegebenenfalls stoppen zu können", resümiert Mark Driver, Research Director der Gartner Group, die gegensätzlichen Positionen im Java-Lager. Schon seit längerem schwelt der Konflikt um Suns eigensinnige Taktik bei der Weiterentwicklung der Java-Plattform. Diese provoziert immer wieder harrsche Kritik seitens Analysten und wichtiger Lizenznehmer wie IBM, Hewlett-Packard, Oracle, Bea Systems und Novell.
Sun hatte seit 1997 die Normierung von Java mit Hilfe der International Organization for Standardization (ISO) vorangetrieben. Deren dafür zuständiges Joint Technical Committee 1 (JTC1) hatte aber Anfang Januar 1999 das bisherige Entscheidungsverfahren "Publicly Available Specification" (PAS) dahingehend geändert, dass künftig private Antragsteller die alleinige Kontrolle über die weitere Entwicklung einer Technologie (Maintenance) an das Komitee abtreten müssen. Diesen Machtverlust wollte Sun als selbsternannter Hüter der Java-Spezifikationen nicht hinnehmen und hoffte, mit Hilfe der in Genf ansässigen Ecma, die enge Beziehungen zur ISO unterhält, doch noch zum begehrten Status als ISO-Standard zu gelangen. Der Umweg hätte den Vorteil gehabt, dass die McNealy-Company die Kontrolle über die Entwicklung der Sprache behalten hätte, da die Ecma ihre Standards im Rahmen des von Sun im Dezember 1998 eingeführten JCP formulieren wollte (siehe Kasten "Java Community Process").
Doch schon Ende letzten Jahres zeichnete sich ab, dass Sun mit der Vorgehensweise der Ecma nicht zufrieden war. Das Unternehmen argumentierte, dass die Offenheit der Ecma-Standards die Einheit von Java 2 gefährde, weil die Organisation keine klaren Vorkehrungen zum Schutz des geistigen Eigentums getroffen habe. Der von Ecma im Quellcode verabschiedete Standard könne von Dritten verändert und erweitert werden, sodass inkompatible Derivate entstehen könnten. Die daraufhin geforderte Einführung von Copyright-Regelungen konnte Sun jedoch nicht durchsetzen.
In einem Brief von George Paolini, Vice President Java Community Software Products & Platforms, an die Genfer Organisation, wurde nun dieser Tage offiziell das Ende der Kooperation besiegelt. Paolini rät zudem, das speziell für die Überwachung des Standardisierungsprozesses gebildete Ecma-Komitee TC41 aufzulösen, da es versagt habe - eine schallende Ohrfeige für Ecma-President Malcome Bermange und seine Mitarbeiter. In ersten Reaktionen hiess es entsprechend verärgert aus Genf, dass Sun die Zeit vieler Experten und das Geld anderer Firmen verschwendet habe. Für Ecma-Generalsekretär Jan van den Beld ist zudem klar, dass Sun sich öffentlich für einen Standard einsetze, intern jedoch nach Belieben herrschen will.
Sun beeilt sich indes, das schlechte Image aufzupolieren, und plant nun, mit Version 2.0 des JCP, seine murrenden Lizenznehmer bei der Stange zu halten. Ein erster Entwurf, der dieser Tage intern mit den Partnern diskutiert wird, sieht vor, dass der Hersteller sich künftig bei der Kontrolle der einzelnen technischen Spezifikationen stärker zurückhalten will und damit nicht nur den Prozess beschleunigen, sondern auch IBMs Forderung nach mehr Demokratie nachkommen würde.
Konkret würde dies vor allem mehr Mitbestimmung bei der Annahme oder Ablehnung von Java Specification Requests (JSR) sowie bei der Zustammenstellung von Expertenteams bedeuten (siehe Kasten "Java Community Process").
Ferner berichten Insider, dass Sun mit dem Entwurf versuche, stärker vom umstrittenen Lizenzierungsprogramm bei der Vermarktung neu entwickelter, Java-2-basierter Anwendungen abzulenken. Letzteres sieht eine "Gebühr" von drei Prozent aller künftigen Einnahmen für Kompatibilitätstests und das Führen des J2EE-Siegels vor. Bisher hat aber kaum einer der rund 200 Lizenznehmer, darunter die Applikations-Server-Hersteller, dem Verfahren zugestimmt. Sie unterstützen dennoch die spezifizierten J2EE-Extensions neben eigenen, proprietären Erweiterungen, von denen sie sich nicht zuletzt Marktvorteile sichern wollen - auf Kosten der Plattformunabhängigkeit Javas.
Java Community Process und Open SourceWeitere Details zum JCP 2.0 sind derzeit noch nicht bekannt. Ob den Äußerungen einzelner Sun-Mitarbeiter, dass grundsätzlich nichts gegen eine Open-Source-Strategie einzuwenden sei, auch Taten folgen, bleibt abzuwarten. Wie das Unternehmen gegenüber dem Brancheninformationsdienst "Computergram" sehr vage formulierte, werde Sun erst dann auf seine Eigentumsrechte an der Sprache verzichten, wenn die Verbreitung und installierte Anwendungsbasis "eine kritische Masse" erreicht habe. Das an der Bereitschaft zur Schaffung eines offenen Standards jedoch nicht zu zweifeln sei, versucht Sun mit dem Hinweis zu belegen, dass man der Apache Software Foundation, Anbieter des quelloffenen und im Internet meistgenutzten Web-Servers, die Java-Servlet- sowie Java-Server-Pages-(JSP-) Technologie zur Verfügung stellen wolle. Auch gibt es Überlegungen, die Netztechnologien "Jini" und "Jain" anderen Communities zur Weiterentwicklung zu überlassen.
Währenddessen rumort es weiter in der Java-Gemeinde. Bereits im letzten Jahr musste Sun lernen, dass seine umstrittene Politik auch Konsequenzen hat. Gefahr droht vor allem seitens der Lizenznehmer, denen der JCP zu langsam geht oder die sich durch proprietäre Erweiterungen Marktanteile sichern wollen. So hatte Microsoft etwa im letzten Jahr nach dem gerichtlichen Verbot von proprietären Erweiterungen in Java einen so genannten Cleanroom-Rivalen namens "Cool" angekündigt, der als "C++-Clone" beschrieben wurde und frei von Java-Code sein soll. Bis heute ist es allerdings bei der bloßen Ankündigung geblieben. In denselben Zeitraum fiel die Gründung des "J Consortium" (http://www.j-consortium.org/), in dem sich unzufriedene Lizenzpartner, allen voran HP und Microsoft, zusammengeschlossen haben. Sie wollen unabhängig von Sun die Entwicklung von Echtzeit-Erweiterungen an der Internet-Programmiersprache vorantreiben. Diese sind vor allem für den Einsatz in Embedded-Umgebungen, etwa in der Fertigungsindustrie, unverzichtbar. Sun erwiderte damals, dass jeder an der "Real Time Expert Group", die innerhalb des JCP die Entwicklung von Echtzeitkomponenten für Java leitet, teilnehmen könne. Die Gründung des Consortiums sei lediglich ein weiterer Versuch, das Java-Lager zu spalten.
Neben den Herstellern ist auch unter Java-Entwicklern seit Ende letzten Jahres eine zum Teil sehr polemisch geführte Debatte um Suns politischen Schlingerkurs entbrannt. Ein Beispiel hierfür ist das populäre Web-Forum http://www.javalobby.com. Dort geht es neben Microsofts widersprüchlicher Rolle bei der Weitentwicklung der Java-Technologie vor allem um die Frage, ob die Standardisierung von Java besser als Open-Source-Verfahren oder per zentral gelenkten JCP basierend auf der Sun Community Source License (SCSL) erfolgen soll. Für Open-Source-Vertreter wie Richard Stallman ist klar, dass Java nur dann plattformunabhängig bleiben kann, wenn die Benutzer bei der Standardisierung die Kontrolle und freie Entscheidung haben. Andere halten Suns Politik für richtig und fühlen sich nicht ausgeschlossen. Vielmehr erlaube der Hersteller, anders als Microsoft, Eingaben zu machen. Vergleichbare Argumente finden sich auch bei den Spekulationen über JCP 2.0. Während einige Anwender den Standardisierungsprozess für Java bereits jetzt als "offen" bezeichnen und daher keine großen Veränderungen erwarten, bleiben andere skeptisch. Sie sehen weder eine Entwicklung Richtung Open Source, noch dass Sun und seine Partner großen Wert auf eine Beteiligung der gesamten Java-Gemeinde legen.
Insgesamt scheint der Streit um Java aber in erster Linie einer zwischen rivalisierenden Lizenznehmern und Sun zu sein. So schlägt die Debatte etwa hierzulande bisher kaum Wellen. Eine kürzlich von der Stuttgarter Java User Group iniitierte Umfrage ergab laut ihrem Vorsitzenden Markus Leutner, Berater Debis, dass sich bisher kaum jemand näher mit diesem Thema befasst hat. Dies bestätigen auch Nachfragen bei Java-Anwendern durch die COMPUTERWOCHE.
Java-Anwender denken pragmatischSie fühlen sich, wie vermutlich das Gros ihrer US-Kollegen, bei der täglichen Projektarbeit wenig von der Debatte und dem JCP beeinträchtigt. Ihre alltäglichen Probleme liegen vielmehr bei der Umsetzung der Spezifikationen und allgemein bei der Anwendungsentwicklung mit Java.
"Für uns spielt es keine Rolle, wer Java standardisiert", kommentiert etwa Gerhard Wanner, Geschäftsführer der IBL Ingenieursbüro Letters aus Leinfelden, die Vorgänge. Seiner Meinung nach sind es vielmehr Suns Lizenzpartner, die unzufrieden sind und etwa beim Thema Embedded-Systeme auf eine zügigere Standardisierung setzen. Wenn Wanner überhaupt eine gewisse Bedrohung für Java erkennen kann, dann am ehesten durch Microsoft mit seiner Cleanroom-Version und proprietären Erweiterungen. "Ich denke aber, dass die Entwickler um diese Problematik wissen und deshalb Java so verwenden, wie es Sun empfiehlt." Zudem rät Wanner, Extensions von Herstellern, die über die Core-Java-Klassen hinausgehen, so wenig wie möglich zu verwenden. Problematisch ist dies allerdings beim derzeitigen Stand der EJB-Spezifikationen, die noch so lax sind, dass Hersteller nicht um eigene Erweiterungen herumkommen. So ist bis heute die Schnittstelle zwischen dem EJB-Server und dem EJB-Container im Standard nicht beschrieben und zwingt die Anbieter zu eigenen Lösungen.
Mit positiven Eindrücken ist Fritz Weichbrodt, Executive Architekturberater bei der Kölner Unternehmensberatung Schumann, vor kurzem von einem strategischen Treffen bei Sun zurückgekehrt. Er glaubt, dass der Hersteller den JCP forcieren will. Sein Kollege Gernot Starke, Java-Experte bei Schumann, rät zudem zu einem pragmatischen Ansatz für die Nutzung der Java-Plattform, bei dem es nicht darauf ankommt, immer die allerneuesten, noch wenig erprobten Spezifikationen sowie alle erhältlichen Erweiterungen zu verwenden. "Wir nutzen in erster Linie Java 1.1, weil dies auch in den Unternehmen derzeit Usus ist." Zugleich hat auch Starke nicht den Eindruck, dass Suns Politik die Arbeit mit Java erschwere: "Ich bin bei allen, zum Teil drastischen Veränderungen der Java-Plattform in den letzten Jahren sehr zufrieden, weil ich den Eindruck habe, dass die Techniker und nicht Markting-Vertreter bei den Spezifikationen das Sagen haben", sagt Starke.
Es gebe natürlich technische Probleme, die aber von Sun in der Bug-Database veröffentlicht und kommentiert werden. Diese Offenheit kenne Starke von manchen anderen, namhaften Herstellern nicht. Trotzdem bestätigt sich in der Praxis der abgewandelte Java-Slogan "Write once - test anywhere". So unterstützt Microsofts VM Java nicht so, wie es sein sollte. Allerdings kann man auch hier über Plugins die Probleme weitgehend lösen. Der Anwender ist also wegen proprietärer Erweiterungen noch lange nicht gezwungen, ausschließlich auf Sun zu setzen. Außerdem, so Starke, habe die zunehmende Verbreitung von Java auch auf dem Server für viele Unternehmen den Vorteil, dass sie auch bei einer Weiterentwicklung der Spezifikationen dennoch immer noch im selben Paradigma blieben. Sie können so schrittweise weitermachen, ohne dass immer die allerneuesten Spezifikationen nötig wären oder sie deswegen in eine technische Einbahnstraße gerieten.
Java Community Process1. Ein Beitrag zahlendes Mitglied der Community (2000 bis 5000 Dollar pro Jahr) sendet Sun einen Java Specification Request (JSR), der Erweiterungen oder Veränderungen an der Java-Plattform vorsieht.
2. Suns Process Management Office akzeptiert oder verwirft den JSR nach eigenem Ermessen, ohne dass die Java-Gemeinde Einspruch erheben kann. Ausschlusskriterien sind:
-Unvollständigkeit des JSR, wie ihn Sun formuliert,
-Konflikte/Doublette zwischen JSR und internen Entwicklungsarbeiten bei Sun
-Konflikte/Doublette mit bereits bestehenden Spezifikationen.
3. Stimmt Sun dem JSR zu, bildet der Hersteller eine Expertengruppe (Call for Expert - "Cafe") und bestimmt deren Teamleiter. Nur Mitarbeiter Suns werden berücksichtigt, Freiberufler sind ausgeschlossen.
4. Die Expertengruppe schreibt einen ersten Entwurf der Spezifikationen. Details dürfen nicht nach außen gegeben werden.
5. Sun verschickt den Entwurf an die Java-Lizenznehmer sowie zahlende Community-Mitglieder.
6. Die Expertengruppe sammelt und beantwortet Rückmeldungen.
7. Die überarbeiteten Spezifikationen werden veröffentlicht und können kommentiert werden.
8. Die Expertengruppe sammelt und beantwortet die Rückmeldungen.
9. Veröffentlichung der endgültigen Spezifikationen, einschließlich einer Referenzimplementierung und Kompatibilitätstests.
10. Ist der Prozess abgeschlossen, behält Sun das Copyright und alle Rechte an den Spezifikationen. Modifikationen sind nicht erlaubt.
Eine detaillierte Übersicht zu den einzelnen Schritten im JCP findetsich unter: http://www.java.sun/aboutJava/communityprocess/java_community_process.html
Adressen zum Java Community Process-<b>Kontakt: community-process@sun.com
-E-Mail für Spezifikationen: jsr-submit@sun.com
-The Java Community Process:
http://java.sun.com/aboutJava/communityprocess
-Einstiegsseite:
http://java.sun.com/aboutJava/communityprocess/getstarted.html
-Seite für Produkte und Feedbacks:
http://java.sun.com/mail/index.html
-Java 2 Platform API Specification Review:
http://java.sun.com/products/jdk/1.2/openprocess
-Java-2-Techniken in JCP:
http://java.sun.com/j2ee/community.html
-Veröffentlichte Java Specification Requests ( JSR):
http://java.sun.com/aboutJava/communityprocess/jsr.html
-Antragsformular für JSR:
http://java.sun.com/aboutJava/communityprocess/jsr_template.html
-Java Specification Participation Agreement:
http://java.sun.com/aboutJava/communityprocess/JSPA.pdf
-Call For Experts (CAFE):
http://java.sun.com/aboutJava/communityprocess/cafe.html
-Java Specification Maintenance:
http://java.sun.com/aboutJava/communityprocess/maintenance.html
-Public-Review-Seite:
http://java.sun.com/aboutJava/communityprocess/review.html
-JCP-Mailing-Listen:
http://java.sun.com/aboutJava/communityprocess/lists.html
Diskussionsforen
-Der Java Gated Community Process:
http://metalab.unc.edu/javafaq/editorials/jcp.html
-Java and Lysenkoism:
http://www.tolstoy.com/samizdat/lysenkoism.html
-Java-Lobby-Website:
http://www.javalobby.com