Jakarta EE: Der Anfang vom Ende oder die Chance für einen Neuanfang?

Der jüngste Lagebericht zur Verhandlung der Java-Namensrechte zwischen Eclipse Foundation und Oracle fällt ernüchternd aus. Inoffiziell geht es um nichts weniger als die Zukunft des Enterprise-Java-Standards: Jakarta EE.

In Pocket speichern vorlesen Druckansicht 56 Kommentare lesen
Lesezeit: 8 Min.
Von
  • Lars Röwekamp
Inhaltsverzeichnis

Mike Milinkovich, Executive Director der Eclipse Foundation, hat einen ernüchternden Lagebericht zu den mittlerweile mehr als 18 Monate anhaltenden Verhandlungen zwischen der Eclipse Foundation und Oracle bezüglich Jakarta EE und der Verwendung von Oracles Markenrechten an Java veröffentlicht. Offiziell geht es um das Recht zur Verwendung der Namensrechte, unter anderen des Namensraums javax. Inoffiziell geht es um nicht weniger als die Zukunft des Enterprise-Java-Standards: Jakarta EE (vormals Java EE).

Vor rund anderthalb Jahren verkündete Oracle die Öffnung von Java EE und übergab wenig später die zugehörigen Sourcen inklusive Technology Compability Kits (TCKs) an die Eclipse Foundation. In den darauffolgenden Monaten investierte die Open-Source-Organisation viel Zeit und Energie in die Portierung der aktuellen Java-EE-Version 8 hin zu einem zu 100 Prozent kompatiblen Jakarta EE 8.

Parallel zu diesen Bemühungen wurde ein eigener Spezifikationsprozess namens Jakarta EE Specification Process (JESP) etabliert, der den bis dato gültigen Java Community Process (JCP) von Oracle ablösen soll. Die Portierung ist mittlerweile abgeschlossen, wie in dem Blog Post "Jakarta EE has landed" von Ian Robinson und Kevin Sutter zu lesen ist.

Nachdem es zunächst so aussah, als ob es nach Oracles "Donation" an die Eclipse Foundation auch bezüglich der Verwendung der damit einhergehenden Marken- und Namensrechte zu einer sinnvollen Einigung kommen könnte, schreibt Milinkovich nun, dass genau damit leider nicht zu rechnen ist:

"It had been the mutual intention of the Eclipse Foundation and Oracle to agree to terms that would allow the evolution of the javax package namespace in Jakarta EE specifications. Unfortunately, following many months of good-faith negotiations, the Eclipse Foundation and Oracle have been unable to agree on terms of an agreement for the Eclipse Foundation community to modify the javax package namespace or to use the Java trademarks currently used in Java EE specifications. Instead, Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications."

Bei der Portierung der Java-EE-Sourcen ist man bei der Eclipse Foundation, nach ersten Gesprächen mit Oracle, zunächst stillschweigend davon ausgegangen, dass bestehende APIs unter dem Namensraum javax weiterverwendet und dort auch im gewissen Rahmen modifiziert werden dürfen. Neue Spezifikationen dagegen sollten unter dem neuen Namensraum jakarta eingeführt werden. Bei einem derartigen Vorgehen wäre eine schrittweise Weiterentwicklung der Plattform bei gleichzeitiger Sicherstellung der Abwärtskompatibilität bestehender Java-EE-Anwendungen problemlos möglich. Eine essenzielle Voraussetzung für die Zukunft des Enterprise-Java-Standards, bedenkt man das seit mittlerweile 20 Jahren gewachsene Ökosystem mit seinen vielen tausend Anwendungen.

Der bisherige Status quo der Verhandlung zwischen der Eclipse Foundation und Oracle aber verbietet genau das. Änderungen an APIs mit dem Namensraum javax sind nicht erlaubt. Finden Änderungen statt, muss das Package umbenannt werden – und auch die zugehörige API. Und als wäre das noch nicht genug, obliegen Spezifikation, die weiterhin auf dem javax-Namensraum basieren, den bisherigen Auflagen von Oracle, die unter anderem das Vorhandensein einer von Oracle lizenzierten Runtime vorsehen: Dazu Milinkovich:

“In addition to the above, any specifications which use the javax namespace will continue to carry the certification and container requirements which Java EE has had in the past. I.e., implementations which claim compliance with any version of the Jakarta EE specifications using the javax namespace must test on and distribute containers which embed certified Java SE implementations licensed by Oracle. These restrictions do not apply to Jakarta EE specifications which do not utilize javax, including future revisions of the platform specifications which eliminate javax.”

Laut Milinkovich haben die Verhandlungen einen Status erreicht, bei dem für beide Seiten das bestmögliche Resultat erzielt wurde. Anders formuliert ist mit weiteren Kompromissen seitens Oracle definitiv nicht zu rechnen.

Aber ist das überhaupt ein Problem? Gehen wir einmal davon aus, dass die Eclipse Foundation, wie im Fall der Portierung von Java EE 8 zu Jakarta 8, zunächst keine Änderung an den bestehenden APIs vornimmt und somit die bestehenden Strukturen – inklusive Spezifikationen und TCKs – beibehalten kann. Bliebe zunächst einmal nur das Problem mit der Runtime. Dies wiederum würde einen dedizierten Hersteller, nämlich Oracle, gegenüber anderen Herstellern bevorzugen, was wiederum gegen die Statuten der Eclipse Foundation verstößt.

Gut, mag sich jetzt der eine oder die andere denken. Man kann in Ausnahmesituationen ja durchaus auch einmal über den eigenen Schatten springen. Schließlich verdankt man Oracle ja den aktuellen Stand der Sourcen. Ganz so einfach ist es allerdings nicht. Für die Eclipse Foundation könnte das punktuelle Aufgeben der bisher vielbeschworenen Herstellerneutralität im schlimmsten Fall bedeuten, dass sie einen Teil ihrer Gemeinnützigkeit und den damit verbundenen Steuervergünstigungen verlieren würde und sich somit nicht mehr von selbst tragen könnte. Für die Organiisation ist es also nicht nur eine Frage von Marken- und Namensrechten, sondern vielmehr eine existenzielle Frage und ein entsprechender Kompromiss mit Oracle somit per Definition nicht gangbar.

Wie aber sähe dann die Alternative aus? Realistisch gesehen bleibt der Eclipse Foundation für alle Versionen nach Jakarta EE 8 nur die Möglichkeit, alle Packages von javax nach jakarta zu portieren. Und das so schnell wie möglich, möchte man nicht noch länger auf eine längst überfällige Weiterentwicklung der Plattform und damit einhergehender Innovationen verzichten müssen. Natürlich müssten auch alle Spezifikationen und die zugehörigen TCKs angepasst beziehungsweise neu geschrieben werden.

Für Projekte, die auf der grünen Wiese starten, wäre das sicherlich kein Problem. Anders dagegen für die vielen, vielen bestehenden Enterprise-Anwendungen, die in den letzten 20 Jahren entstanden sind. Selbst wenn man willens wäre, die notwendigen Refactorings am eigenen Code, inklusive hoffentlich vorhandener Tests, vorzunehmen, setzt dieser mit hoher Wahrscheinlichkeit auf Libraries, Frameworks und proprietären Erweiterungen von Anwendungsservern auf, die noch nicht kompatibel mit dem neuen Standard sind. Das Chaos scheint vorprogrammiert.

Macht es dann überhaupt noch Sinn am Standard festzuhalten? Welchen Mehrwert hätte dieser dann noch? Ein großes Plus wäre nach wie vor, vorausgesetzt alle Application-Server-Hersteller spielen weiter mit, die Herstellerunabhängigkeit. Es wird auch weiterhin unabhängige TCKs geben, welche die Kompatibilität der verschiedenen Implementierungen sicherstellen.

Ein weiteres, nicht zu unterschätzendes Plus stellt der Spezifikationsprozess (JESP) dar. Durch die Beteiligung unterschiedlichster Interessengruppen ist sichergestellt, dass nicht nur durch die Belange eines einzelnen Herstellers die zukünftige Entwicklung des Standards vorangetrieben wird. Ganz im Gegenteil. Nimmt man einmal die jüngste Entwicklung des Eclipse-Foundation-Projekts MicroProfile als Muster, bekommt man einen Eindruck davon, wie schnell und Community-getrieben es zukünftig vorangehen könnte.

Bleibt nach wir vor die Herausforderung der Abwärtskompatibilität. Ein sicherlich unschönes, aber nicht unlösbares Problem, wie David Blevins (Gründer und CEO von Tomitribe) in seinem Blog-Post "Jakarta EE: a new hope" im Abschnitt "Backwards compability is possible" beschreibt. Die Application Server müssten lediglich das tun, was sie heute sowie schon machen und mittels Bytecode-Creation und/oder -Manipulation die alten Java-EE-Sourcen für die neue Wunderwelt Jakarta EE aufbereiten. Blevins:

"For a Jakarta EE implementation to migrate your bytecode from javax to jakarta is ‘more of the same.’ There will be some challenges, but it is ultimately how everything works anyway."

Bleibt zu hoffen, dass David Recht behält und die Application-Server-Hersteller willens sind, diesen Schritt zu gehen. Wenn ja, dann steht der Zukunft von Jakarta EE als Enterprise-Java-Standard nichts im Wege. Wenn nicht, wird Jakarta EE zukünftig lediglich eines von vielen Enteprise-Java-Frameworks sein. ()