Jakarta EE 10: Das erste große Release seit 5 Jahren zielt auf Cloud-Anwendungen

Nach mehr als fünf Jahren ist mit Jakarta EE 10 das erste neue Feature-Release des Java-Enterprise-Standard erschienen.

Lesezeit: 18 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 8 Beiträge

(Bild: Peshkova / shutterstock.com)

Von
  • Lars Röwekamp
Inhaltsverzeichnis

Mit einem Vierteljahr Verzögerung ist das ursprünglich für Ende Juni geplante Jakarta EE 10 erschienen. Nach dem Umzug zur Eclipse Foundation und den damit verbundenen organisatorischen Herausforderungen – unter anderem musste der durch Oracle geschützte Namespace javax.* flächendeckend durch jakarta.* ersetzt werden – ist Jakarta EE 10 das erste neue Feature-Release seit fünf Jahren.

Die eigenen Ziele sind dabei hochgesteckt: "Building an Open Source Ecosystem for Cloud Native Enterprise Java", so zu lesen auf der Homepage von Jakarta EE. Das ist auch zwingend notwendig, möchte man in Zeiten von Containern, Cloud Native und Co bestehen.

Um besser zu verstehen, welchen hohen Stellenwert das aktuelle Jakarta EE Release in der mittlerweile 20 Jahre währenden Historie des Java-Enterprise-Standards innehat, hilft ein kurzer Blick zurück:

Das letzte echte Feature-Release für Java Enterprise gab es mit Java EE 8 im August 2017. Damals wurden unter anderem eine eigenständige Security API, JSON-Binding und ein JAX-RS Reactive Client eingeführt. Die folgenden beiden Releases Jakarta EE 8 und Jakarta EE 9 brachten zunächst keine weiteren neuen Features, sondern wurden lediglich dazu verwendet, den Umzug weg von Oracle hin zur Eclipse Foundation zu realisieren und damit einhergehend die Namespaces von javax.* auf jakarta.* zu migrieren. Auch der Sprung auf die vor Jakarta EE 10 aktuelle Version 9.1 ist lediglich als Maintenance Release zu verstehen, das zwar die Unterstützung von Java SE 11 mit sich brachte, aber keine neuen Features.

Der Weg von Java EE 8 zu Jakarta EE 10 brachte einige Umstellungen mit sich (Abb. 1).

Das bedeutet im Umkehrschluss, dass die bis dato aktuelle Version Jakarta EE 9.1 aus Sicht der angebotenen Funktionsweise nach wie vor auf dem Stand von Java EE 8 ist, einem Stand von vor fünf Jahren! Genau dies ist der Grund, warum das aktuelle Release 10 so sehnsüchtig erwartet wurde. Im Vordergrund steht dabei vor allem die Frage, ob man in Zukunft auch in hochdynamischen Umgebungen wie der Cloud noch auf den Enterprise Java Standard setzen kann.

Auch wenn aufgrund des im positiven Sinne äußerst transparenten Jakarta EE Specification Process die Neuerungen im Vorfeld bekannt waren, lohnt sich ein eingehender Blick. Insbesondere vor dem Hintergrund, dass mit CDI Lite und dem Core Profile die Grundlage geschaffen wurde, Jakarta EE basierte Services zukünftig ohne den Ballast eines Application-Servers, schlank in einer Cloud-nativen Umgebung betreiben zu können.

Bereits mit der Version 2.0 und somit als Teil von Java EE 8 wurde die CDI-Spezifikation (Contexts Dependency Injection) in die Bereiche Core CDI, CDI in Java SE und CDI in Java EE unterteilt. Während der Bereich Core CDI die grundlegende Funktionsweise von CDI spezifiziert, definieren die anderen beiden Bereiche zusätzliche Features für die jeweiligen Umgebungen Java SE beziehungsweise Java EE.

Die neue Spezifikation CDI 4.0 geht noch einen Schritt weiter. Mit der Einführung von CDI Lite und CDI Full findet eine weitere Unterteilung von Core CDI statt. Während CDI Full als Basis für Anwendungsserver fungieren soll, kommt CDI Lite immer dann zur Anwendung, wenn es darum geht, ein schmales Runnable beispielsweise in Form eines Microservice zu erzeugen.

CDI 4.0 unterscheidet zwischen CDI Lite und CDI Full (Abb. 2).

Damit stellt sich die Frage, warum es überhaupt noch CDI Full gibt. Der eben skizzierte Optimierungsschritt basiert in weiten Teilen darauf, dass zur Laufzeit auf den Einsatz von Reflection verzichtet wird, was einige Restriktionen mit sich bringt. So darf eine auf CDI Lite aufsetzende Anwendung keine passivierbaren Scopes (Session und Conversation) anbieten. Auch Decorator- und Specializes-Annotationen sind tabu. Viel schwerer ins Gewicht fallen dürfte aber für die meisten Anwendungsfälle, dass der Mechanismus der CDI Portable Extensions ebenfalls nicht in CDI Lite vorhanden ist. Mit Hilfe der Portable Extensions lässt sich auf einfache Art und Weise die Funktionalität des CDI-Containers via Drag&Drop erweitern.

Fairerweise soll nicht unterschlagen werden, dass es für die Portable Extensions in CDI Lite ein Pendant namens Build Compatible Extension gibt. Es ist davon auszugehen, dass es viele der aktuell in der JEE-Community etablierten Portable Extensions künftig ebenso in Form von Build Compatible Extensions geben wird.

Die CDI-Lite-API ist für sich genommen bereits spannend, spielt aber ihre volle Stärke erst im Zusammenspiel mit einer weiteren Neuerung der Jakarta EE 10 Spezifikation aus: dem Core Profile. Das neue Profile ist bewusst deutlich schlanker gehalten als die beiden bisherigen Varianten Full Profile und Web Profile und hat lediglich sieben APIs:

  • Jakarta Annotations 2.1
  • Jakarta CDI 4.0 Lite
  • Jakarta Dependency Injection 2.0
  • Jakarta Interceptors 2.1
  • Jakarta JSON Processing 2.1
  • Jakarta JSON Binding 3.0
  • Jakarta RESTful Web Services 3.1

Damit ist es besonders gut zum Entwickeln von Headless-Anwendungen wie Microservices geeignet.

Das neue Core Profile ist bewusst schlank gehalten (Abb. 3).

Dank der geringen Größe des resultierenden Artefakts und der verkürzten Start-up-Phase durch die Anwendung der Compile-Time-Optimierung via CDI Lite entstehen geeignete Kandidaten für hochdynamische und automatisch skalierende Systeme für Cloud-native und Kubernetes-Anwendungen.

Bei einem genaueren Blick auf die APIs des Core Profile fällt auf, dass sie nahezu identisch mit den Jakarta-EE-APIs des Eclipse MicroProfile sind. Das kommt nicht von ungefähr: Es ist ein erklärtes Ziel beider Spezifikationen, dass zukünftige Versionen des Eclipse MicroProfile auf der jeweils aktuellen Version des Jakarta EE Core Profile aufsetzen sollen. Durch diesen Schritt wird eine verbesserte Kompatibilität zwischen den beiden erreicht. Zu den weiteren Kandidaten für eine künftige Kompatibilität mit dem Jakarta EE Core Profile gehören helidon.io, Quarkus und Micronaut.