Enterprise Java: Jakarta EE 9 in Sicht

Inhaltsverzeichnis

Nach den Plänen der Eclipse Foundation soll Jakarta EE 9 Mitte 2020 erscheinen. Die Arbeitsgruppe hat den Releaseplan laut dem Chef der Eclipse Foundation, Mike Milinikovich, einstimmig abgesegnet. Inhaltlich sind keine großen Funktionen zu erwarten, auch wenn bezüglich der Umstellung immer wieder der Begriff "Big Bang" fällt. Dieser bezeichnet jedoch kein Feature-Feuerwerk, sondern die vollständige Umstellung auf den Jakarta-Namespace.

Bereits im Herbst letzten Jahres hatte Oracle in einer offiziellen Mail mit Vorschlägen für die Zukunft von Jakarta den sogenannten Big-Bang-Ansatz offiziell als wünschenswert bezeichnet: Alle Spezifikations-APIs sollen demnach im Jarkarta-Namespace neu aufgestellt werden, also als jakarta.* verfügbar sein.

Aufräumarbeiten statt Featuritis

Inhaltlich stehen auf dem Weg zu Jakarta EE 9 vor allem Aufräumarbeiten an. Ein entsprechendes Zurechtstutzen (Pruning) war ebenfalls Bestandteil von Oracles Vorschlägen. Nach dem aktuellen Releaseplan der Eclipse Foundation entfallen im kommenden Release Jakarta XML Registries, Jakarta XML RPC, Jakarta Deployment und Jakarta Management. Die Interoperabilität zu Enterprise Java Beans (EJB) ist ebenfalls eingeschränkt.

Die Liste der von Jakarta EE 8 für das aktuelle Release aktualisierten Spezifikationen umfasst 29 Einträge, und die vollständige Aufzählung lässt sich dem Releaseplan entnehmen. Zusätzlich gelten die beiden Spezifikationen Jakarta Enterprise Beans 2.x API group und Jakarta Enterprise Web Services, JSR 109 in Jakarta EE 9 als optional.

Quereinsteiger von Java SE

Ein paar Neuzugänge wird Jakarta EE 9 im Vergleich zur Vorversion mitbringen. Dabei handelt es sich jedoch nicht um neue Spezifikationen, sondern um Quereinsteiger aus Java SE 8. Auch sie werden damit im Jakarta-Namespace landen.

Die fünf Spezifikationen sind Jakarta Activation, Jakarta XML Binding, Jakarta XML Web Services, Jakarta Web Services Metadata und Jakarta SOAP with Attachments. Nur die erste Spezifikation in der Aufzählung gilt als benötigt, während die restlichen als optional gekennzeichnet sind.

Schnelle Umsetzung

Milinkovich nennt für die Umsetzung neben dem Umzug der APIs auf jakarta.* und dem Aufräumen noch die Kompatibilität zu Java SE 11 als wichtiges Ziel. Allerdings bleibt – anders als ursprünglich von Oracle vorgeschlagen – Java SE 8 die Basis. Konkret müssen alle APIs mit Letzterem kompiliert werden. Implementierungen von Jakarta EE 9 Web Profile und Full Profile erfordern jedoch eine Zertifizierung für die Kompatibilität mit Java SE 11. Eine Zertifizierung zur Java-SE-8-Kompatibilität ist zusätzlich optional möglich.

Erklärtes Ziel von Jakarta EE 9 ist eine geringe Einstiegshürde für neue Hersteller und Implementierungen zu Gunsten einer größtmöglichen Kompatibilität. Außerdem soll eine stabile Plattform mit dem neuen Namespace entstehen, der die Migration und Tests so einfach wie möglich gestaltet.

Die Jakarta EE Working Group hat zudem das Ziel, die neue Version so schnell wie möglich bereitzustellen. Die zeitliche Planung im Releaseplan bezeichnet die Arbeitsgruppe als aggressiv. So seien die dort genannten Zeiträume als geplante Schätzdaten zu betrachten, und die Working Group wird bei wichtigen Meilensteinen die Planung potenziell anpassen.

Zeitplan und Leidenschaft der Community

Der derzeitige Zeitplan sieht folgendermaßen aus:

• 14. Februar: Verfügbarkeit aller API-JARs (Java Archive)
• 13. März: Die Änderungen der Plattform-TCK (Technology Compatibility Kit) sind vollständig
• 4. Mai: Erste Release Candidates für Full Profile und Web Profile
• 12. Juni: Start der Abstimmung über die Veröffentlichung der endgültigen Releases von Full Profile und Web Profile

Der Blogbeitrag von Mike Milinkovich betont die Bedeutung der Community und der gemeinsamen Überlegungen beim Erstellen des Releaseplans. Es sei spannend gewesen, zu beobachten wie die "... ähmmm leidenschaftliche ..." Diskussionen schließlich zu einem breiten Konsens geführt hätten. (rme)