Kolumne: EE Insights

javax vs. jakarta: Eine Zusammenfassung der Namespace-Problematik von Jakarta EE

Christian Kaltepoth

Viel tut sich momentan bei der Java Enterprise Edition: der Umzug nach Eclipse, die Umbenennung in Jakarta EE, der neue Community-getriebene Prozess, die Konsolidierung und Weiterentwicklung der Standards. In der neuen Kolumne „EE Insights“ hält uns Christian Kaltepoth auf dem Laufenden und versorgt uns mit Insider-Wissen aus dem Jakarta-EE-Universum.

Christian Kaltepoth

Die schlechte Nachricht kam Anfang des Monats. In einem ausführlichen Blog-Post teilte Mike Milinkovich, geschäftsführender Direktor der Eclipse Foundation, der Community mit, dass die Verhandlungen mit Oracle gescheitert sind. Auch wenn man bereits zuvor zwischen den Zeilen lesen konnte, dass die Gespräche alles andere als einfach waren, so war diese Information doch ein Schock. Schließlich haben sich die Verhandlungen über 18 Monate hingezogen. Nach all dieser Zeit zu keinem positiven Ergebnis zu kommen, ist natürlich deprimierend. Das lässt sich kaum schönreden.

Aber worum ging es eigentlich genau in diesen Verhandlungen? Schließlich sind fast alle Bestandteile von Java EE bereits vor vielen Monaten migriert worden und es gab mit Eclipse Glassfish 5.1.0 bereits ein erstes Release der ehemaligen Referenzimplementierung unter dem Dach der Eclipse Foundation. Bei den langwierigen Gesprächen zwischen Oracle und der Eclipse Foundation ging es hauptsächlich darum, inwieweit und in welcher Form Jakarta EE die Marke „Java“ nutzen darf, über die Oracle seit der Übernahme von Sun Microsystems seine schützende Hand hält. Was sich zunächst nach einem mehr oder weniger unwichtigen Detail anhört, hat weitreichenden Einfluss auf Jakarta EE. Zum einen tragen viele der Spezifikationen und Technologien die Marke Java in ihrem Namen. Man denke nur an das Java Persistence API, JavaServer Faces, Java Servlet, Java Message Service und viele weitere. Es ging also unter anderem darum, ob diese Namen auch weiterhin so verwendet werden dürfen. Viel wichtiger war allerdings ein anderer Aspekt. Bei den Verhandlungen ging es auch um die Frage, ob Jakarta EE den Package-Namespace javax weiterhin nutzen darf. Ursprünglich war javax für Extensions gedacht, also Klassen, die nicht direkt durch das JRE bereitgestellt werden. Heute gibt es diesbezüglich auch einige Ausnahmen, da das JRE auch einige javax-Klassen enthält, was die ursprüngliche Idee etwas verwässert. Die Nutzung dieses Namespaces unterliegt aber auch heute noch strengen Regeln. Wer ein Package innerhalb des javax-Namespaces nutzen will, musste bisher den Weg über einen Java Specification Request (JSR) innerhalb des Java Community Process gehen.

Und woran sind die Verhandlungen nun genau gescheitert? Das lässt sich leider nicht mit hundertprozentiger Sicherheit sagen, da keine Details öffentlich gemacht wurden. Verständlicherweise, da es sicherlich niemandem hilft, wenn sich die beiden Parteien nun gegenseitig versuchen den schwarzen Peter in die Schuhe zu schieben. Wenn man sich allerdings etwas auf die Suche begibt, so sind doch einige Hinweise über den Inhalt der Gespräche zu finden. So beispielsweise im Protokoll der letzten Vorstandssitzung der Eclipse Foundation, welche Ende März in Boston stattgefunden hatte. Dort war nämlich der aktuelle Stand der Verhandlung mit Oracle eines der Hauptthemen.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: 30+ Seiten Java-Wissen von Experten

Sie finden Artikel zu EnterpriseTales, Microservices, Req4Arcs, Java Core und Angular-Abenteuer von Experten wie Uwe Friedrichsen (codecentric AG), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

API Summit 2019
Thilo Frotscher

API-Design – Tipps und Tricks aus der Praxis

mit Thilo Frotscher (Freiberufler)

Golo Roden

Skalierbare Web-APIs mit Node.js entwickeln

mit Golo Roden (the native web)

Mike Milinkovich schilderte im Rahmen der Sitzung, dass die Verhandlungen sehr schwierig und zeitintensiv waren und vor allem deutlich mehr Budget benötigt haben, als zuvor angenommen. Trotzdem sei man bis zu diesem Zeitpunkt zu keinem zufriedenstellenden Ergebnis gekommen. Im Vorstand wurde damals bereits offen die Möglichkeit eines Abbruchs der Verhandlungen diskutiert. Offensichtlich beharrte Oracle in den Vertragsentwürfen auf Konditionen, welche nicht nur Jakarta EE, sondern sämtlichen Eclipse-Projekte eingeschränkt hätten. Dies wurde vom Vorstand als inakzeptabel angesehen. Aus dem Protokoll lässt sich lesen, dass es im Speziellen um die Distribution von nicht durch Oracle zertifizierte Java Runtimes zusammen mit Eclipse-Projekten ging. In diesem Kontext wird auch beschrieben, dass unter den von Oracle vorgeschlagenen Konditionen beispielsweise die Veröffentlichung des Eclipse Compiler for Java (ECJ), dem Java Compiler der Eclipse IDE, nicht mehr möglich wäre. Außerdem wurde diskutiert, ob die Eclipse Foundation durch eine Unterzeichnung der Verträge nicht Gefahr läuft, ihren Status als Non-Profit-Organisation zu verlieren, da man argumentieren könnte, dass die Herstellerunabhängigkeit nicht mehr gegeben wäre. Ob diese Gefahr wirklich realistisch bestand, lässt sich schwer beurteilen. Aber die steuerlichen Vorteile einer Non-Profit-Organisation zu verlieren, wäre für die Eclipse Foundation sicherlich fatal gewesen. Eine endgültige Entscheidung über das weitere Vorgehen bezüglich der Verhandlungen wurde laut des Protokolls in der Sitzung nicht gefällt. Allerdings ermächtigte der Vorstand den Direktor, zum Wohle der Foundation die Gespräche mit Oracle zu beenden, falls es sich nicht vermeiden lässt.

No Deal – Wie geht es jetzt mit Jakarta EE weiter?

Nun ist das Kind also in den Brunnen gefallen. Die Verhandlungen sind gescheitert und es wird kein entsprechendes Übereinkommen zwischen Oracle und der Eclipse Foundation geben. Was genau bedeutet das für die Zukunft von Jakarta EE? Zunächst müssen die verschiedenen Technologien umbenannt werden, sodass der Markenname „Java“ nicht mehr in deren Titel auftaucht. Das wäre sicherlich noch einigermaßen zu verkraften. Ob es jetzt das Java Persistence API oder das Jakarta Persistence API ist, wird dem durchschnittlichen Entwickler vermutlich recht egal sein. Leider hört es aber bei den reinen Namen nicht auf. Auch die populären Akronyme werden in Zukunft teilweise nicht mehr erlaubt sein. Mike Milinkovich nennt in seinem Blog-Post explizit EJB, JPA und JAX-RS als Beispiele für Abkürzungen, die nicht mehr verwendet werden dürfen. Diese Einschränkung schmerzt natürlich sehr, da die Akronyme in der Praxis sehr viel häufiger gebraucht werden, als die vollständigen Namen. In der Community waren zwischenzeitlich sogar Zweifel daran aufgekommen, ob Oracle rechtlich gesehen überhaupt die Nutzung der Akronyme einschränken darf. Es scheint aber unwahrscheinlich, dass jemand es darauf ankommen lässt und im Zweifel einen Prozess gegen Oracle bestreiten möchte, um dies zu klären.

Aber das weitaus größere Problem ist ein anderes. Ohne die angestrebte vertragliche Basis wird Jakarta EE die Spezifikationen zukünftig nicht mehr im javax-Namespace weiterentwickeln dürfen. Die Betonung liegt dabei auf dem Wort „weiterentwickeln“. Es ist Jakarta EE weiterhin erlaubt, die transferierten APIs aus den javax-Packages unverändert zu veröffentlichen. Das heißt also, solange das API binärkompatibel zur vorherigen Version bleibt, wäre beispielsweise eine Veröffentlichung des Jakarta Persistence APIs möglich. Sobald eine Klasse oder ein Interface allerdings für eine neue Spezifikationsversion verändert wird, ist die Nutzung des javax-Packages nicht mehr erlaubt. Maßgeblich sind dabei die Signature-Tests des Java EE TCKs.

In der Praxis bedeutet das also, dass sämtliche Weiterentwicklung an einer Spezifikation zwangsweise bedeutet, dass ein Teil oder sogar das gesamte Package umbenannt werden muss. Das heißt wiederum, dass aus javax.servlet.Servlet bald jakarta.servlet.Servlet werden könnte. Die Auswirkungen einer solchen Änderung sind natürlich fatal. Im ersten Schritt bedeutet es, dass die Migration der eigenen Anwendungen von Java EE auf Jakarta EE nicht ohne Änderungen am Quellcode möglich sind. Das ist natürlich ein Bruch mit einem der Hauptprinzipien von Java EE, nämlich der Abwärtskompatibilität. Man könnte natürlich argumentieren, dass eine Migration der Package-Namen im eigenen Quellcode eigentlich mit einem „Search & Replace“ schnell erledigt ist, was sicherlich teilweise stimmt. Allerdings betrifft die Änderungen an der Namen der Packages ja nicht nur den eigenen Quellcode, sondern auch alle eingesetzten Bibliotheken. Auch diese müssen entsprechend angepasst werden. Dabei stellt sich die Frage, ob das in allen Fällen so einfach möglich ist. Besonders Open-Source-Komponenten, die heute nicht mehr aktiv weiterentwickelt werden, könnten schnell zum Problem werden.

Big Bang Proposal / Incremental Proposal

Aktuell werden in der Jakarta EE Community verschiedene Möglichkeiten diskutiert, mit der Situation umzugehen. Dabei haben sich bisher zwei mögliche Ansätze herauskristallisiert, welche in die nähere Auswahl fallen. Mit dem sogenannten „Big Bang Proposal“ würden mit dem Release von Jakarta EE 9 alle APIs in den neuen jakarta-Namespace verschoben werden. Das würde bedeutet, dass Anwendungen bei der Migration auf Jakarta EE 9 einmalig angepasst werden müssten. Da Jakarta EE anschließend von allen Restriktionen befreit wäre, könnte das eine annehmbare Lösung sein.

Die Alternative zu diesem Vorgehen ist der „Incremental Proposal“. Bei diesem Ansatz würde nur die aktiven Spezifikationen, welche ihr API auch wirklich verändern, in den neuen Package-Namespace verschoben. Stabilere APIs, die nicht angepasst werden, würden zunächst im alten javax-Namespace verbleiben. Das könnte beispielsweise bedeuten, dass JAX-RS in Jakarta EE 9 auf das jakarta-Package migriert wird, das unveränderte JSP-API würde aber auch weiterhin im javax-Namespace verbleiben. Dieses Verfahren hat den klaren Vorteil, dass bei einer Migration auf Jakarta EE 9 weniger Arbeit entsteht, da nur einige Spezifikationen von der Umbenennung betroffen sind. Dieser Ansatz spielt sicherlich nur dann seine Stärke aus, wenn man annimmt, dass ein nicht unerheblicher Anteil der APIs erst einmal nicht von Änderungen betroffen ist. Allerdings kann es auch bedeuten, dass die APIs nach und nach umbenannt werden müssen, sodass mit jedem folgenden Jakarta EE Release weitere Anpassungen nötig werden. Zum aktuellen Zeitpunkt werden die verschiedenen Vor- und Nachteile noch heftig diskutiert. Die finale Entscheidung soll offenbar schon im Juni getroffen werden. Die Eclipse Foundation hat den Zeitraum für Diskussionen jedenfalls auf den 9. Juni festgelegt.

Die Jakarta EE Community hat somit ein weitere große Hürde zu stemmen. Inzwischen wurde bereits damit begonnen, die Spezifikationen umzubenennen, um die Wortmarke „Java“ aus den Namen zu streichen. Im Vergleich zu den notwendigen Änderungen am Package-Namespace ist das aber sicherlich der deutlich einfachere Teil. Für die Zukunft von Jakarta EE ist es überlebenswichtig, bezüglich der Migration in einem neuen Package-Namespace eine gute und praktikable Lösung zu finden. Aber man darf sich auch nichts vormachen. Es wird sicherlich ein steiniger und anstrengender Weg. Aber er lohnt sich. Schließlich bedeutet es, dass Jakarta EE von weiteren Restriktionen befreit wird und in Zukunft deutlich unabhängiger weiterentwickelt werden kann. Aus Sicht der Nutzer ist das Problem vielleicht auch erst einmal gar nicht so akut. Alle Hersteller von Anwendungsservern werden sicherlich Möglichkeiten schaffen, sowohl ältere Java-EE-Anwendungen, als auch neue auf Jakarta EE basierende Anwendungen zu unterstützen. Aber langfristig wird diese Umstellung wohl alle betreffen.

Geschrieben von
Christian Kaltepoth
Christian Kaltepoth
Christian Kaltepoth arbeitet als Senior Developer bei ingenit GmbH & Co. KG in Dortmund. Sein Schwerpunkt ist die Entwicklung von webbasierten Unternehmensanwendungen auf Basis von Java-EE-Technologien. Darüber hinaus ist er in mehreren Open-Source-Projekten wie Apache DeltaSpike, Rewrite, PrettyFaces und Togglz aktiv. Er ist Mitglied der JSR 371 Expert Group und ein regelmäßiger Sprecher auf Konferenzen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: