Die Geschichte von Oracle und Jakarta EE
Im Herbst 2017 entschloss sich Oracle zur Überführung der Java EE in ein Open-Source-Projekt unter dem Dach der Eclipse Foundation. In meinem Beitrag https://javaeeblog.wordpress.com/2017/09/13/oracle-schlaegt-verlagerung-von-java-ee-in-die-eclipse-foundation-vor/ von damals war ich zuversichtlich, dass dieser Schritt Java EE aus dem starren Korsett des JCP befreien und der Plattform die Modernität und Agilität ermöglichen würde, die neben der Verlässlichkeit und Stabilität in aktuellen Projekten benötigt wird.
Erste Zweifel kamen mir bei der Nachricht, dass Oracle die Rechte am Namen “Java EE” nicht abgeben würde. Als Folge davon müssen alle Vorkommen von “Java EE” durch den neuen Namen “Jakarta EE” ersetzt werden. Nun ist Textersatz nicht wirklich kompliziert, also was soll’s?
Es verbleibt aber genauso das geistige Eigentum an den bislang von Oracle geführten Spezifikationen in den Händen von Oracle, so dass sich nach meiner Beobachtung nun viele Monate lang JEE-Experten damit beschäftigen durften, Spezifikationen so umzuschreiben, dass sie zwar inhaltlich kompatibel bleiben, aber keine schützenswerte Originalformulierung mehr enthalten.
Diese Zeit hätte man sehr gut in die Weiterentwicklung der Plattform stecken können. Glücklicherweise gibt es das Projekt MicroProfile (https://microprofile.io/), das in der letzten Zeit ganz und garnicht paralysiert herumgelegen hat, sondern mit wirklich hoher Innovationsgeschwindigkeit JEE-Erweiterungen entwickelt hat, die dringend notwendig sind, um JEE in der Greifvogelvoliere von immer kleineren Services irgendwo in den Wolken flugfähig zu halten.
Nun kommt aber noch der dicke Brocken, dass man sich nicht auf eine Weiterentwicklung des Paketnamensraums javax einigen konnte: Die bisherigen Pakete dürfen nur unverändert weiter genutzt werden, Neu- und Weiterentwicklungen müssen in neuen Paketen (jakarta) geschehen. Einfacher Textersatz ist hier natürlich wiederum möglich, bricht aber die Kompatibilität bestehender Anwendungen und Bibliotheken mit der neuen, paketumbenannten Plattform.
Wer sich nun mit Häme zu Aussagen wie “JEE ist eh Sch…, habe ich doch schon lange gesagt. Mit Spring ist alles besser!” versteigt, sollte mal nachschauen, wieviele javax er in seinem Code findet.
Mir erschließt sich nicht, welchen Wert Oracle in den zurückgehaltenen Rechten sieht. Für mich als Entwickler und Berater scheint der Wert zukünftig bei 0 $ zu liegen. Und dafür erzeugt man große Verärgerung und Kosten bei Kunden und Anwendern? Nun bin ich kein Jurist, insbesondere kein Markenrechtler. Ich muss das also nicht verstehen.
Blick nach vorne
Was kann man nun in dieser verfahrenen Situation tun? Man könnte eine Koexistenz von javax und jakarta anstreben, Neuerungen wie gefordert in jakarta einführen und javax als Basis nutzen. Basis im Sinne von Basisklasse bzw. Basisinterface bedeutet aber eine (zu) enge Kopplung an die alten Versionen: API-Änderungen müssten sich i. W. auf Erweiterungen beschränken und man würde die ganzen alten Zöpfe weiter mit sich herumschleppen.
Es wird also darauf hinauslaufen, dass betroffene Pakete von javax.xyz in jakarta.xyz umbenannt werden. Das bedeutet zwar breaking Changes, bietet aber die Möglichkeit, veraltete APIs abzustoßen. Die erste Version, die dies betrifft, ist Jakarta EE 9, denn Jakarta EE 8 ist vollständig kompatibel zu Java EE 8, nutzt also weiterhin die bestehenden javax-Pakete. Es wird derzeit diskutiert, ob die Umbenennung der Pakete in einem Big Bang geschehen soll oder inkrementell immer dann, wenn Änderungen an einer Teilspezifikation durcheführt werden sollen. Ersteres hätte den Charme, mit einem – allerdings großen – Schritt sofort Unabhängigkeit zu erreichen. Bei der inkrementellen Vorgehensweise könnte man darauf spekulieren, dass sich manche Teile der Plattform zumindest in näherer Zukunft gar nicht ändern werden und man den Aufwand in diesem Bereich also sparen könnte. Ein Festlegung der Marschrichtung sollte noch im Juni 2019 geschehen.
Die Kompatibilität von Anwendungen älterer Versionen zu neuen Laufzeitplattformen ist einer der großen Werte der JEE. Ihn gilt es auf jeden Fall zu erhalten. Ich bin mir sicher, dass die Anbieter der modernen JEE-Server wie WildFly, OpenLiberty, Payara oder TomEE Mittel finden werden, z. B. durch Bytecode-Manipulation zur Deployment-Zeit, Altanwendungen mit javax-Paketen auf Jakarta-EE-9+-Servern lauffähig zu erhalten.
Das Ganze erzeugt nicht gerade unerheblichen Aufwand. Er ist es aber wert, angenommen zu werden. Kaum eine Plattform für Enterprise-Anwendungen hat ein ähnliches Gewicht, eine ähnliche Verbreitung in Projekten bei gleichzeitiger Flexibilität hinsichtlich der Laufzeitplattform – ob klassische Server wie die oben genannten oder Micro-Frameworks wie KumuluzEE, Meecrowave oder Quarkus. Wenn nun juristische Verkrustungen entfallen und die weitere Entwicklung ohne Korsett geschehen, kann’s doch nur super werden!
Bis bald – vielleicht auch in einem unserer Trainings in Berlin, Bielefeld, Köln oder bei Ihnen!
https://gedoplan-it-training.de/
