Java EE vs. Jakarta EE, oder doch etwas Neues?

Bereits am 3. Mai 2019 gab Mike Milinkovich, Chef-Verhandler der Eclipse Foundation Inc., einen Überblick (Update on Jakarta EE Rights to Java Trademarks) über die Verhandlungen mit Oracle Inc. bezüglich der Übergabe von Java EE an die Eclipse Foundation. 18 Monate nach der großen Ankündigung stehen die derzeitigen Lösungen weit hinter den Erwartungen zurück.

Markus Karg hat in seinem Blog in der Java Aktuell bereits mehrfach über die Übergabe und die zu erwartenden Schwierigkeiten seine Befürchtungen Kund getan (siehe Java Aktuell Ausgabe 06/2018 Seite 9 und Java Aktuell Ausgabe 01/2019 Seite 10). Auf Heise lässt sich der bisherige Werdegang sehr gut nachvollziehen. Ein guten Einstiegspunkt gibt folgender Beitrag: Jakarta EE: Der Anfang vom Ende oder die Chance für einen Neuanfang? Sowie die beiden Kommentare Kommentar: Java EE ist am Ende und Kommentar: Eine Chance für Jakarta EE.

Durch die aktuelle Haltung von Oracle Inc. müssen sämtliche Java EE Spezifikationen einen neuen Namespace bekommen, um weiterentwickelt werden zu können. Aktuell ist angedacht, den Namespace javax.* nach jakarta.* umzubenennen. Dies wiederum würde die Rückwärtskompatibilität, welche bisher als großer Pluspunkt von Java EE angeführt wurde, zu Nichte machen. Sämtliche Java EE Anwendungen müssen an die neuen Namespaces angepasst werden, um auf aktualisierten Applikationsserver lauffähig zu sein. Den Entwicklungsaufwand sowie die Testaufwände wären enorm.

Aktuell diskutiert die Jakarta EE Community eifrig darüber, wie dieser Schritt vollzogen werden kann. Es haben sich inzwischen zwei Lager gebildet, die einerseits eine komplette Umstellung aller Namespaces in einem Schritt durchzuführen (Big Bang) und andererseits die Umstellungen nur dort durchzuführen, wo Änderungen an der Spezifikation erfolgen (Incremental).
Variante Eins würde bedeuten, dass nicht nur Java EE 8 und Jakarta EE 8 gleichen Inhalt hätten, sondern auch Jakarta EE 9, diesmal aber mit angepasstem Namespace. Erst ab Jakarta 10 würden dann wieder Neuerungen in die Spezifikation aufgenommen, so der Plan.
Variante Zwei hätte den Vorteil, dass bereits mit Jakarta EE 9 Neuerungen in die Spezifikation mit aufgenommen würden, aber eben nur diese Spezifikationen einen neuen Namespace bekommen. Vermutlich würde bei diesem Vorgehen viele zukünftige Jakarta EE Spezifikationen nach und nach Änderungen des Namespace erfahren, wodurch bestehende Anwendungen an zukünftige Jakarta EE Versionen immer wieder erneut angepasst werden müssten, sofern sie diese Spezifikation selbst verwenden.

Aus meiner Sicht scheint Variante Eins für Unternehmen, welche bisher gegen Java EE entwickeln, die einzig vernünftige Lösung. Ich kann es mir nicht vorstellen, unsere Anwendung bei jedem neuen Jakarta EE Release erneut auf Änderungen im Namespace zu überprüfen. Auch ist es aus heutiger Sicht nicht wirklich vorstellbar Anwendungen zusammen mit einem passenden Applikationsserver einzufrieren, und ja nichts mehr zu ändern…
Daher lieber einen „Big Bang“, und einmal einen Mehraufwand, um sich anschließend wieder wie gewohnt um die Probleme unserer Kunden zu kümmern, und nicht an fortlaufende Anpassungen am Namespace.

Auch für uns als Hersteller von Software-Generatoren wäre eine „Big Bang“-Lösung selbstverständlich einfacher Hand zu haben. Unsere Kunden hätten mit einem einzigen Upgrade der Generator-Version, Ihre gesamte Anwendung Jakarta EE 9+ ready. Die Umstellung der Namespaces übernimmt der Generator in Eigenregie, so dass die Umstellung ein rein administrativer Akt ist.

Letztendlich wird die Community entscheiden, wie das weitere Vorgehen nach Erscheinen der Jakarta EE 8 Version aussieht. Wichtig für alle Nutzer von Java EE / Jakarta EE ist jedoch bald Klarheit über die etwas verfahrene Situation zu haben, um für zukünftige Projekte Planungssicherheit zu bekommen. Die Gefahr, dass bei allzu langen Release Zyklen zwischen den Versionen nützliche und wichtige Neuerungen zu lange auf sich warten lassen, ist jetzt schon zu spüren. Sicherlich gibt es in Unternehmen schon Überlegungen, was die Alternative zu Jakarta EE wäre. Einige in der Community beschwören schon das bisherige Eclipse Microprofile als den neuen Standard herauf.
Von daher mein Rat: Lasst es endlich krachen 🙂