Einführung
Für diejenigen unter euch, die seit JEE 8 sich nicht mehr mit der Thematik auseinandergesetzt haben,
eine kurze Einleitung in das Thema, um die aktuelle Position von Jakarta EE besser zu verstehen.
Diese kann übersprungen werden, wenn man sich mit der Geschichte von Jakarta EE 8 bereits auskennt.
Mit der Java Enterprise Edition (JEE bzw. vormals J2EE) wurde 1999 [1] eine Sammlung von Spezifikationen zur Entwicklung von Unternehmensanwendungen im Java-Umfeld erstellt. Dies geschah bis 2017 unter der Führung der Oracle Corporation. Entsprechend lagen alle Rechte von JEE bei der Firma Oracle.
2017 wurde die Weiterentwicklung an die Eclipse Foundation übergeben. Da Oracle jedoch die Namensrechte behalten wollte, wird JEE unter neuem Namen weiterentwickelt – Jakarta EE.
Der erste Jakarta EE Release (Jakarta EE 8) wurde im Januar 2019 angekündigt. Dieser war jedoch ein rein technischer Release (Daten wurden von Oracle zur Eclipse Foundation migriert), und unterschied sich kaum von dem historischen Vorgänger Java EE 8. Die Spezifikationen haben sich in diesem Release nicht geändert, lediglich der Prozess dahinter [2]. Erste neue Features wurden dadurch erst in Jakarta EE 9 erwartet.
Nun war es endlich so weit. Nach mehrmaligen verschieben wurde Ende 2020 Jakarta EE 9 veröffentlicht. Ich möchte euch hier einen Überblick über die aktuelle Lage (ein halbes Jahr nach dem Release) geben. Gibt es aufregendes Neues? Was hat sich geändert? Und wurden die Erwartungen erfüllt?
Status Quo
Auf dem ersten Blick schein sich vieles geändert zu haben, denn alle Spezifikationen sind nun eine Hauptversion höher [3]. Doch der erste Blick trügt – leider.
Die einzelnen Haupt-Versionsupdates kommen durch den „Big Bang“ zustande. Durch das beharren von Oracle auf den Namensrechten muss die Eclipse Foundation aufwendig alle package namespaces von javax.* zu jakarta.* migrieren [4]. Diese migrierten Spezifikationen stellen den jeweiligen neuen Major Release dar.
Eine schwerwiegende Folge hieraus ist, dass Jakarta EE 9 somit nicht mehr abwärtskompatibel ist! Weder mit Java EE 8 noch mit Jakarta EE 8.
Diese einfach erscheinende Änderung, die gar nicht so schlimm zu seinen scheint, macht jedoch größeren Aufwand, und nicht nur das Leben des Eclipse Foundation Teams schwer, sondern auch von allen JEE Produkt-Entwicklern! Folglich ist nicht nur JEE 8 nicht mehr aufwärtskompatibel, sondern auch alle JEE 8 Projekte bzw. Produkte!
Somit gibt es aktuell kaum kompatible Application Server [6]. Lediglich die „Referenzimplementierung“ Eclipse GlassFish und Open Liberty Beta (von IBM) erfüllen aktuell die vollen Spezifikationen. Dies scheint sich auch in naher Zukunft nicht zu ändern.
Hierzu äußerte sich unter anderem das Unternehmen „Red Hat“ (Entwickler des WildFly Application Servers) in einem Blogeintrag [7]. Wo es möglich war, wurden „native“ EE 9 implementierte Libraries verwendet (Weld, Hibernate Validator, Jakarta EL … ), jedoch setzt der WildFly – so wie die meisten anderen Application Server – noch auf viele EE 8 APIs. Um dieses Problem zu umgehen, werden diese vorübergehend mittels „byte code transformation“ zugänglich gemacht. Hierfür hat die Eclipse Foundation extra ein Projekt, Eclipse Transformer [8], erstellt, um die Adaption an EE 9 einfacher zu gestalten.
Mit diesem konnte der WildFly in Version 23.0.1.Final inzwischen das Jakarta EE 9 Web Profile erfüllen.
Eine weitere Änderung ist das Streichen von irrelevanten Spezifikationen [5]. Hierzu gehören:
– XML Registries 1.0
– XML RPC 1.1
– Deployment 1.7
– Management 1.1
– Distributed Interoperability
Hinzu kommt noch eine kleine Namensänderung der Java API „RESTful Web Services“ (JAX-RS) zu
„Jakarta Restful Web Services“ (Jakarta REST).
Ausblick
Der langsame Fortschritt lässt vielleicht bei dem ein oder anderen Sorgenfalten entstehen, ob sich dies wirklich in der nahen Zukunft ändert. Daher nun ein Ausblick auf die bevorstehenden Änderungen und was wir darüber wissen.
Denn solange muss eventuell gar nicht auf ein neues Jakarta EE gewartet werden, ein Minor Release (Jakarta 9.1) wartet schon hinter der nächsten Ecke [9] (17.05.2021 [10][11]) . Mit diesem Update soll der lang ersehnte Support für Java 11 kommen. Die Unterstützung von Java 8 bleibt dabei noch bestehend. Auch im 9.1 Release werden noch keine funktionellen Updates enthalten sein. Genaueres kann man hier nachlesen. Nach aktuellem Stand liegen alle Milestones leicht hinter der Zeit und wurden einmalig um einen Monat verschoben.
Die ursprünglich für JEE 9 geplante NoSQL API soll nun mit Jakarta EE 10 kommen[12].
tl;dr
Jakarta EE 9
– Keine Abwärts bzw. Aufwärtskompatibilität zu JEE 8
– Änderungen des package namespaces von javax.* zu jakarta.*
– Entfernen von irrelevanten Spezifikationen
– JDK 8 Support
– JAX-RS heißt nun Jakarta REST
Jakarta EE 9.1
– Jakarta EE 9.1 Fokus liegt auf JDK 11 Support
– CORBA wird nicht weiterentwickelt (wurde von Java SE 11 entfernt)
– XML Binding, XML Web Services, Web Services Metadata, SOAP wird nicht weiterentwickelt (wurde von Java SE 11 entfernt)
Jakarta EE 10
– Jakarta NoSQL erst mit Jakarta 10
Quellen:
[1] https://en.wikipedia.org/wiki/Jakarta_EE
[2] https://jakarta.ee/about/jesp/
[3] https://jakarta.ee/specifications/platform/9/
[4] https://eclipse-foundation.blog/2020/12/08/jakarta-ee-9-delivers-the-big-bang/
[5] https://jakarta.ee/specifications/platform/9/jakarta-platform-spec-9.html#a2333
[6] https://jakarta.ee/compatibility/#tab-9
[7] https://www.wildfly.org/news/2020/11/12/Jakarta-EE-9-with-WildFly-Preview/
[8] https://projects.eclipse.org/projects/technology.transformer
[9] https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan
[10] https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1#:~:text=Jakarta%20EE%209.1%20Release%20Plan,-The%20Jakarta%20EE&text=On%20Feb%209%2C%202021%2C%20it,the%20Jakarta%20EE%20Steering%20Committee
[11] https://projects.eclipse.org/projects/ee4j.glassfish/releases/6.1.0
[12] https://jakarta.ee/specifications/nosql/
[13] https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan