... sonst ändert sich nichts*

Im Jahr 2017 kündigte Oracle an, Java EE 8 an die Eclipse Foundation zu übergeben. Im September 2019 erschien daraufhin die im Funktionsumfang unveränderte, aber durch die Eclipse Foundation erstellte Version Jakarta EE 8. Damals wurde angekündigt, dass ein Jahr später Jakarta EE 9 erscheinen soll, was im November 2020 der Fall war.

Der Umzug von Oracle zur Eclipse Foundation bedingt eine Umbenennung der Java-Pakete von javax.** zu jakarta.*, was mit dem jetzt veröffentlichten Jakarta EE 9 vollzogen wird. Nach längeren Diskussionen hat man sich für eine Big Bang*-Strategie entschieden, d.h. die Umbenennung erfolgt nicht schrittweise, sondern vollständig in einem Schritt. Das hat weitreichende Konsequenzen, unter anderem:

  • Jakarta EE 9 ist nicht abwärtskompatibel zu Jakarta EE 8 bzw. Java EE 8
  • Alle Spezifikations-Dokumente müssen angepasst werden
  • Alle Implementierungen der Spezifikation müssen angepasst werden
  • Es werden neue Jakarta EE-kompatible Applikations-Server benötigt
  • Alle vorhandenen Java EE-Anwendungen, die auf Jakarta EE 9 umgestellt werden, benötigen Codeanpassungen und müssen neu gebaut werden.

Alle APIs haben zudem eine neue Major-Versionsnummer, um die nicht vorhandene Abwärtskompatibilität zu signalisieren:

Abbildung 1: Alle Spezifikationen erhalten eine neue Versionsnummer
Abbildung 1: Alle Spezifikationen erhalten eine neue Versionsnummer

Die alten Zöpfe ...

Die in der Abbildung 1 dunkelrot markierten Spezifikationen entfallen in Jakarta EE 9.

  • Jakarta XML Registries
  • Jakarta XML RPC
  • Jakarta Deployment
  • Jakarta Management

Der Wegfall dieser APIs ist vermutlich in den meisten Projekten zu verkraften.

... und doch ein bisschen Neues

Da die Package-Umbenennung zu weitreichenden Anpassungen führt, ist sie, neben dem Entfernen der genannten Spezifikationen, nahezu die einzige Änderung in Jakarta EE 9. Es kommt keine neue Funktionalität hinzu, einige APIs wurden aber ergänzt. Diese waren früher Bestandteil des JDK. Da Jakarta EE 9.1 kompatibel zu JDK 11 sein soll, wurden diese hinzugefügt:

  • Jakarta Activation 2.0
  • Jakarta Web Services Metadata 3.0
  • Jakarta XML Binding 3.0 (optional)
  • Jakarta XML Web Services 2.0 (optional)
  • Jakarta SOAP with Attachments 2.0 (optional)

Umstellen oder nicht?

Es stellt sich die Frage, ob Projekte jetzt schon umgestellt werden sollten. Alleine die Tatsache, dass es zur Zeit nur einen Applikations-Server gibt, der Jakarta EE-kompatibel ist (GlassFish 6.0.0 RC2), macht eine Umstellung zum jetzigen Zeitpunkt schwierig. Jakarta EE 9 ist eher für die Tool-Anbieter aus dem Jakarta EE-Umfeld von Bedeutung, die ihre Programme anpassen müssen. Wenn alle Anpassungen durchgeführt wurden, macht eine Umstellung bei Erscheinen von Jakarta EE 10 mit neuen Funktionalitäten wieder Sinn.

Fazit

Auch wenn in Jakarta EE 9 keine neue Funktionalität hinzugekommen ist, so ist dieses wichtige Release doch die Grundlage für die Neuerungen ab Jakarta EE 10. Altlasten wurden entsorgt und der Abschluss der aufwändigen Umstellung auf die neuen Paketnamen macht den Weg für eine gute Zukunft frei.

Quellen