Dieser Umstand stellt einen zusätzlichen Vorteil dar, wenn es um Investitionssicherheit geht. Es wurde in Kauf genommen, dass dadurch veraltete Technologien weitergeführt werden mussten. Nach ersten kleineren Versuchen, in der Vergangenheit dieses Vorgehen zu ändern, setzt man jetzt mit Jakarta EE 10 zum großen Wurf an.
Totgesagte leben bekanntlich länger. Speziell im Fall von JEE hatte man sogar mehrfach das Gefühl, dass die Totsagungen eher zu einer deutlichen Trotzreaktion führten. Das letzte Mal wurde JEE 2017 totgesagt, als Oracle verkündete, Java EE nicht mehr (selbst) fortführen zu wollen. Es folgte das letzte Release unter dem Oracle-Mantel (Java EE 8) und die Übergabe an die Eclipse-Foundation, verbunden mit einem Streit über die Package-Namen, der damit endete, dass die javax Packages alle in Jakarta umbenannt wurden. 2019 war die Übergabe an die Eclipse Foundation abgeschlossen. Es folgte das erste Jakarta-Release, das völlig identisch zu Java EE 8 war. Dementsprechend wurden die alten Package-Namen übernommen. Jakarta EE 9 wurde dann komplett dazu genutzt, die Umbenennung der Packages durchzuführen. Es wurde 2020 releast. Selbst das nächste Release (Jakarta EE 9.1), das nur die Umstellung von Java 8 auf Java 11 beinhaltete, brachte keine (echten) neuen Features.
Stay tuned
Regelmäßig News zur Konferenz und der Java-Community erhalten
In Summe lässt sich also sagen: Seit 2017, was immerhin fünf Jahre her ist, wurden hinsichtlich der Funktionalität keine maßgebenden Veränderungen in EE realisiert. Selbst das Update auf Java 11 ist mittlerweile veraltet. Das aktuelle Long Term Support Release ist Java 17. Umso spannender ist es, zu beobachten, was sich inhaltlich in EE 10 getan hat.
Entfernen alternativer Komponentenmodelle
Bevor CDI mit Java EE 6 eingeführt wurde, war EJB das übergreifende Komponentenmodell von Java EE (und zuvor von J2EE). Der Umstand, dass EJB ein so schwergewichtiges Komponentenmodell war, verdeutlichte, dass nicht alles, was man in JEE gerne als Komponente modelliert hätte, eine EJB sein konnte.
Das führte dazu, dass (nahezu) jede der einzelnen EE-Spezifikationen ein eigenes, spezialisiertes (und leichtgewichtiges) Komponentenmodell als Ergänzung zu EJBs entwickelte. Dies begann bei JSF Managed Beans, ging über JPA-Entitäten bis hin zu mit @Provider annotierten Komponenten in JAX-RS.
Die unterschiedlichen Komponentenmodelle waren von Anfang an eine Herausforderung, wenn es um die Integration der verschiedenen Spezifikationen miteinander ging. Am deutlichsten wird das bei der Securityspezifikation. Je nachdem, in welcher Spezifikation man unterwegs ist, gibt es einen anderen Weg, um herauszubekommen, wer der/die aktuelle Benutzer:in ist und ob er/sie sich in einer bestimmten Rolle befindet (z. B. Http-ServletRequest#getUserPrincipal und HttpServlet-Request#isUserInRole, EjbContext#getCallerPrincipal und EjbContext#isCallerInRole, SecurityContext in JAX-RS und weitere Optionen).
Als CDI mit Java EE 6 kam, war es schnell das vorherrschende Komponentenmodell und wurde nach und nach in nahezu allen anderen EE-Spezifikationen neben dem eigenen Komponentenmodell genutzt. Hier zeigte sich allerdings der Nachteil der strikten Policy der Abwärtskompatibilität von JEE-Spezifikationen: Man wird die spezifischen Komponentenmodelle der einzelnen Specs nicht mehr so ohne Weiteres los. Folglich hatte man anstatt eines übergreifenden Komponentenmodells für ganz Java EE nur ein weiteres Komponentenmodell neben den spezifischen Modellen der Einzelspezifikationen.
Den ersten Schritt ging die EJB-Spec mit den EJB Entity Beans, die schon in Java EE 6 als „pruned“ markiert wurden. In der Praxis waren sie längst durch JPA Entities ersetzt worden. Zu diesem Zeitpunkt wurden sie allerdings noch nicht aus der Spec entfernt. Gleichermaßen stellte die JSF-Spec ziemlich schnell fest, dass lieber CDI Beans als JSF Managed Beans verwendet werden sollten. Mit JSF 2.2 wurden daher für alle JSF Scopes auch CDI Scopes zur Verfügung gestellt.
Wenngleich es diese einzelnen Versuche gab, alternative Komponentenmodelle (zumindest teilweise) loszuwerden, dauerte es jetzt, bis Jakarta EE 10 CDI zum offiziellen Komponentenmodell von JEE machte. Das zeigt sich jetzt dadurch, dass alle Spezifikationen Überlegungen anstellen, wie sie das eigene Komponentenmodell zugunsten von CDI loswerden können. Bei den meisten Spezifikationen erfolgt dies, indem bestehende Annotations entweder deprecated werden oder (z. B. im Fall von JSF), wenn sie bereits deprecated waren, komplett entfernt werden.
Spezialfall EJB
Die schwergewichtigen EJBs waren, wie bereits erwähnt, der Grund für die vielen spezifischen Komponentenlösungen. Gleichzeitig beinhalteten EJBs aber auch viel Funktionalität, die man ab und an benötigt und die anderweitig im EE-Standard nicht verfügbar war. Dazu gehör(t)en @Startup, @Schedule, @Roles-Allowed, @TransactionAttribute, @Asynchronous und @Lock. Um ein leichtgewichtiges Komponentenmodell wie CDI als Ersatz für EJB zu etablieren, wird folglich auch Ersatz für diese Funktionalität benötigt. Bei einigen der Annotations (@RolesAllowed, @Transactional) ist dies bereits in der Vergangenheit geschehen. Seit der Herausgabe von Jakarta EE 10 soll diese Lücke jetzt komplett geschlossen werden und mit @Asynchronous ist damit bereits begonnen worden.
Ziel ist hier offenkundig eine Ablösung des schwergewichtigen EJB-Standards zugunsten von leichtgewichtigeren CDI Beans, die dann von Fall zu Fall mit der benötigten Funktionalität angereichert werden können.
Core Profile
Sicherlich wird es kurzfristig nicht passieren, dass der EJB-Standard komplett aus der Jakarta-EE-Spezifikation entfernt wird. Dennoch ist es schon länger das Ziel, es auch neuen Application-Servern zu ermöglichen, eine Enterprise-Server-Zertifizierung zu erhalten, ohne den kompletten Funktionsumfang von EE implementieren zu müssen. Bereits in Java EE 6 wurde dafür das Konzept der Profile und als erstes Beispiel dafür auch das Web Profile eingeführt. Die Idee war es, Servern zu ermöglichen, moderne Laufzeitumgebungen zu entwickeln, die Java-EE-zertifiziert werden können, aber dennoch nicht den Ballast alter Spezifikationen mitschleppen müssen.
Allerdings enthielt gleichermaßen das Web Profile damals noch einige Spezifikationen, die man aus heutiger Sicht nicht in einem modernen Server erwarten würde. Dazu gehörten z. B. JSP und eine leichtgewichtige Version von EJB. Aus heutiger Sicht darf JSF ebenfalls maximal als optional in der Webentwicklung angesehen werden, SPAs haben dem Standard längst den Rang abgelaufen. Teil des Web Profile ist JSF aber dennoch.
Mit Jakarta EE 10 soll nun ein weiteres Profil dazukommen: das Core Profile. Die Idee des Core Profile ist, die wirkliche Kernfunktionalität eines Application-Servers dort zu bündeln, um so z. B. auch Microservices-Entwicklung mit einem EE-zertifizierten Server zu ermöglichen. Geplant ist aktuell eine Bündelung von CDI, JSON-B und JAX-RS.
Das Core Profile ist allerdings noch nicht finalisiert und zudem ist noch offen, ob eher mehr (Was ist z. B. mit Messaging oder JPA?) oder doch weniger Technologien (Wenn ich einen komplett Message-basierten Microservice habe, brauche ich kein REST Framework.) darin landen.
Fazit
Jakarta EE 10 ist das erste Release unter dem Namen Jakarta EE, in dem echte Weiterentwicklung stattgefunden hat. Am interessantesten dürfte dabei die Einführung eines neuen Profils, des Core Profile, sein. Mit ihm besteht die Möglichkeit, minimale EE-Server dahingehend zu spezifizieren, wie sie in Microservices-Landschaften eingesetzt werden können.
Des Weiteren sind die Änderungen im Bereich der Komponentenmodelle spannend. CDI soll das allgemeingültige Komponentenmodell aller EE-Spezifikationen werden. Das bedeutet, dass die vielen verschiedenen Komponentenmodelle der einzelnen Spezifikationen Schritt für Schritt zunächst deprecated und dann entfernt werden sollen. Dazu zählen EJBs genauso wie JSF Managed Beans und auch alle Objekte, die in JAX-RS mit @Context injiziert werden können. Insbesondere bei Letzteren zeigt sich jedoch die Herausforderung des Vorhabens. Bei JSF dürfte es kaum noch Altanwendungen geben, die auf JSF Managed Beans (und nicht auf CDI) basieren (was auch daran liegen könnte, dass es überhaupt noch sehr wenige JSF-Anwendungen gibt).
Bei JAX-RS sieht die Sache anders aus: Diese allgemein verbreitete Spezifikation wird noch von vielen Anwendungen genutzt. Die Deprecation und somit auch das spätere Entfernen betreffen hier demzufolge viele Anwendungen. Im Vergleich zu JSF kommt erschwerend hinzu, dass der Zeitraum zwischen Deprecation und Entfernen recht kurz werden könnte, da die Releasezyklen von Jakarta EE deutlich verkleinert werden sollen.
Der Spagat ist hier, einerseits dafür zu sorgen, dass die Spezifikation dem aktuellen Stand der Entwicklung entspricht, und zudem, wie aus einem Guss wirkt (eben mit einem gemeinsamen Komponentenmodell), und andererseits das hohe Gut des langfristigen Supports alter Applikationen aufrecht zu erhalten. Wenn hier bei der Spezifikation nicht aufgepasst wird, droht eine der Stärken, die Java EE noch ausgezeichnet haben, in Jakarta EE verloren zu gehen. Das ist die Abwärtskompatibilität und damit einhergehend die Investitionssicherheit.
Mit Jakarta EE ist das noch nicht der Fall. Vielmehr gelingt der Spagat aktuell gut. Es gibt aber Kräfte, denen die Erneuerung und das Abschneiden alter Zöpfe nicht schnell genug gehen. Es bleibt also spannend, welchen Weg Jakarta EE in Zukunft geht, insbesondere da kurze Releasezyklen angestrebt werden.
In diesem Sinne – Stay tuned.
Links & Literatur
[2] https://blogs.oracle.com/javamagazine/post/java-for-the-enterprise-what-to-expect-in-jakarta-ee-10
[3] https://newsroom.eclipse.org/eclipse-newsletter/2022/april/top-5-new-features-coming-jakarta-ee-10
