Von Java EE 8 zu Jakarta EE 8

Oracle verabschiedet sich von der Java Enterprise Edition, da die Eclipse Foundation Java EE aus urheberrechtlichen Gründen ohne das Warenzeichen “Java“ unter einem neuen Namen „Jakarta“ übernimmt.

Wenn Jakarta bekannt klingt, dann deshalb, weil es nicht das erste Mal ist, dass dieser Name für ein auf Java basierendes Projekt verwendet wird. Von 1999 bis 2011 betrieb die Apache Software Foundation das Projekt Apache Jakarta, das alle Open-Source-Java-Bemühungen von Apache abdeckte.

Der 10. September 2019 war der Tag, auf den die Java-Gemeinde gewartet hatte: Die Eclipse Foundation veröffentlicht Jakarta EE 8, die erste offizielle Veröffentlichung des Java EE-Nachfolgers, fast zwei Jahre nach der Geburt des Eclipse EE4J-Projekts. Die Eclipse Foundation veröffentlicht damit eine erste Version des Java EE-Nachfolgers, die vollständig aus den jeweiligen Eclipse-Projekten hervorgeht und alle Phasen des neuen Jakarta EE-Spezifikationsprozesses durchlaufen hat. Obwohl Jakarta EE 8 von einer neuen Organisation nach neuen Regeln und Prozessen herausgegeben wurde, ist der rein technische Zustand genau derselbe wie bei Java EE 8.

Die letzte Version von Java EE selbst war Java EE 8 im August 2017. Java EE 8 und seine Referenzimplementierung GlassFish 5 bilden die Grundlage für die erste Version von Jakarta EE (Jakarta EE 8 und Eclipse GlassFish 5.x). Es lohnt sich daher, einen genaueren Blick auf die Neuerungen und Besonderheiten von Java EE 8 im Vergleich zu seinen Vorgängern zu werfen.

Eines der Hauptziele der Java EE 8-Spezifikation ist die konsequente Weiterführung dessen, was in Java EE 6 und Java EE 7 begonnen wurde, insbesondere die Unterstützung der beiden Mottos “Modern Web Development” und “Ease of Development”.

Themen wie HTTP/2 mit Push statt Pull, erweiterte JSON-Unterstützung und ein reaktives Programmiermodell stehen ebenso auf der Liste der neuen Funktionen, wie die erweiterte Unterstützung der neuen Java 8 Lambda- und Stream-APIs oder CDI-Erweiterungen wie asynchrone Ereignisse.

Daher beschloss Oracle, Java EE vollständig auf eine Open-Source-Stiftung zu übertragen. In Abstimmung mit den Java EE-Partnern Red Hat und IBM wurde beschlossen, Java EE zusammen mit der vollständigen Referenzimplementierung und dem „Technology Compatibility Kit“, wie bereits oben erwähnt, an die Eclipse Foundation zu übertragen. Aufgrund des enormen Arbeitsaufwandes, der mit diesem Transfer verbunden war, wurde der Prozess in drei Phasen aufgeteilt.

Phase 1 : Übertragung von API- und Implementierungscode und Freigabe eines verifizierten Builds

Beispielsweise wurde JSF 2.3 als Snapshot von seinem master-Branch übertragen. JSF 2.2 und frühere Versionen verbleiben an ihrem ursprünglichen Ort und werden von der Eclipse Foundation weder gepflegt noch unterstützt. Nach der Übertragung des Quellcodes wurde der gesamte Code mit Hilfe von Eclipse Build-Servern erstellt, und das Ergebnis wurde in ein Maven-Repository gestellt.

Bei den API JAR-Dateien wurde die Maven GroupId von javax.* in jakarta.* geändert, was anzeigt, dass es sich um die von Eclipse erzeugten Build-Artefakte handelt.

Übrigens, die ursprüngliche Version der APIs unter der Jakarta GroupId sind Java EE 8-zertifiziert, nicht Jakarta EE 8-zertifiziert. Beispielsweise ist jakarta.faces:jakarta.faces-api:2.3.1 identisch mit javax.faces:javax.faces-api:2.3 und beide sind Java EE 8-zertifiziert, aber die erste ist aus github.com/eclipse-ee4j und die zweite aus github.com/javaee gebaut.

Phase 2: Übertragung von Technology Compatibility Kit Code, Einrichtung eines neuen Spezifikationsprozesses, Neudefinition der Begriffe und Veröffentlichung eines Builds mit neuer Marke

In dieser Phase wurden für alle Spezifikationen neue vereinfachte und konsistentere Namen geschaffen. Die neuen Namen beginnen alle mit Jakarta und werden von einer einfachen Beschreibung der Spezifikation gefolgt, wobei inkonsistente Füllwörter wie architecture, api und service vermieden werden.

Zum Beispiel:

  • Java EE 8: Java Server Faces (JSF) –>  Jakarta EE 8: Jakarta Faces
  • Java EE 8:  Java Persistence Api (JPA) –>  Jakarta EE 8: Jakarta Persistence
  • Java EE 8:   Enterprise Java Beans (EJB) –>  Jakarta EE 8: Jakarta Enterprise Beans
  •   Java EE 8:  Java Server Pages (JSP) –> Jakarta EE 8: Jakarta Server Pages
  •  Java EE 8:  Java API for RESTful Web Services (JAX-RS) –>  Jakarta EE 8: Jakarta Restful Web Services
  •  Java EE 8:  Contexts and Dependency Injection for Java (CDI) –> Jakarta EE 8: Jakarta Contexts and Dependency Injection

Jakarta EE 8 wurde mit im Wesentlichen leeren Spezifikationsdokumenten veröffentlicht. Der Grund dafür ist der große Zeitaufwand für die rechtliche Klärung und Übertragung dieser Dokumente. Dies wurde einfach nicht rechtzeitig für die Veröffentlichung von Jakarta EE 8 abgeschlossen. Vorerst können die Anwender der Technologien die Evaluationsversion der entsprechenden Java EE 8-Dokumente lesen. Die Aktualisierung auf die Jakarta EE-Versionen der APIs ist der erste kleine Schritt, den die Benutzer unternehmen können, um sich auf die bevorstehenden größeren Änderungen vorzubereiten. In einem Maven-Projekt kann man JSF z. B. wie folgt ändern: von

<dependency>
    <groupId>javax.faces</groupId>
    <artifactId>javax.faces-api</artifactId>
    <version>2.3</version>
    <scope>provided</scope>
</dependency>

zu:

<dependency>
    <groupId>jakarta.faces</groupId>
    <artifactId>jakarta.faces-api</artifactId>
    <version>2.3.2</version>
    <scope>provided</scope>
</dependency>

Phase 3: Übertragung und Aktualisierung der Spezifikationsdokumente, Bereinigung der Spezifikationen, Änderung des API-Paketnamens und Release von JDK 11

Der Quellcode des Spezifikationsdokuments (meist in AsciiDoc) sollte übertragen werden. Genau wie die JavaDocs für die APIs werden die Spezifikationsdokumente aktualisiert, um die neue Terminologie zu verwenden. Angesichts der großen Zeitspanne, die seit der Veröffentlichung von Java EE 8 vergangen ist, wird Jakarta EE 9 offiziell die Unterstützung von JDK 11 erfordern.

In den Jakarta EE-kompatiblen Produkten gibt es eine vollständige Liste der Anwendungsserver, die mit der neuesten Jakarta EE 8-Spezifikation kompatibel sind, einschließlich GlassFish v5.1, Payara Server 193, Wildfly 18.0.0 oder OpenLiberty 19.0.0.9. GlassFish v5.1 ist ein Open-Source Java EE/Jakarta EE-Anwendungsserver. In den vergangenen Jahren war er lange Zeit die offizielle Java EE-Referenzimplementierung. Jetzt wird er als Teil des Eclipse EE4J-Projekts an die Eclipse Foundation gespendet. Wildfly 18.0.0 ist der Open-Source-Anwendungsserver JBoss von RedHat mit neuem Branding.

Lasst uns einen kurzen Blick auf das, was bisher getan wurde und was für die folgenden Projekte geplant ist, werfen. JSF 3.0 wird all die unnötigen Kleinigkeiten entfernen müssen, die sich im Laufe der Jahre angesammelt haben und die aufgrund der strengen Anforderungen an die Abwärtskompatibilität beibehalten wurden. So wird zum Beispiel  das „JSF native managed bean“ System endlich vollständig entfernt werden, nachdem es seit JSF 2.0 schrittweise veraltet ist. Daher wird JSF 3.0 nicht abwärtskompatibel sein. Es wird auch erwartet, dass es den Weg fortsetzen wird, mehr eigene Artefakte auf CDI zu übertragen, womit JSF in JSF 2.2 und JSF 2.3 begonnen hatte.

Obwohl JAX-RS in gewissem Umfang CDI unterstützt, hat die Tatsache, dass die JAX-RS-Ressourcen keine CDI- Beans sind, die Spezifikation unnötig zurückgehalten und Verwirrung gestiftet, selbst seit JAX-RS in EE 6 (2009) eingeführt wurde. Interceptors wird oft als Teil von CDI angesehen, aber in Wirklichkeit handelt es sich um eine separate Spezifikation – eine Unterspezifikation von EJB. Eine der sinnvollsten Änderungen, die in Betracht gezogen wird, ist das Hinzufügen der Fähigkeit eines Interceptors, nicht nur das Ziel der Methode und ihre Parameter, sondern auch das Ziel der Beans zu verändern.

Sehen wir uns einmal an, wie eine Gradle-Builddatei aussieht, die die Jakarta EE 8-Abhängigkeit enthält.

In build.gradle:

plugins {
    id 'java'
    id 'war'
}

group 'com.trivadis.jakarta'
version '1.0-SNAPSHOT'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencies {
    providedCompile 'jakarta.platform:jakarta.jakartaee-api:8.0.0'
}

war {
    archiveName 'jakarta-ee-app.war'
}

Jakarta EE 9

Jakarta EE 9 soll am 30. Juni 2020 veröffentlicht werden. Das Ziel der Veröffentlichung von Jakarta EE 9 ist es, eine Reihe von Spezifikationen zu liefern, die funktionell ähnlich wie Jakarta EE 8 sind, jedoch im neuen Jakarta EE 9-Namensraum jakarta.* liegen.

Jakarta EE 8 konzentriert sich auf die Aktualisierung seines Prozesses, um sich weiterzuentwickeln. Die ersten Aktualisierungen der Funktionen werden in Jakarta EE 9 erfolgen. Die wichtigste Aktualisierung, die in Jakarta EE 9 erwartet wird, ist die Jakarta NoSQL-Spezifikation.

Jakarta NoSQL ist eine Spezifikation, die darauf abzielt, die Integration zwischen Java-Anwendungen und NoSQL-Datenbanken zu erleichtern und eine Standardlösung zu fördern, um sie mit einem hohen Abstraktionsniveau zu verbinden. Dieses Feature ist fantastisch. Es ist auch ein großer Schritt, um die Java-Plattform näher an einen cloud-nativen Ansatz heranzuführen, da NoSQL-Datenbanken in Cloud-Umgebungen weit verbreitet sind. Die Jakarta NoSQL Spezifikation basiert auf Eclipse JNoSQL, das seine Referenzimplementierung sein wird.

Darüber hinaus werden mit dem Release Jakarta EE 9 Spezifikationen aus Jakarta EE 8 entfernt, die alt, optional oder veraltet waren. Damit wird die Menge der APIs verringert, um sicherzustellen, dass es für neue Anbieter einfacher ist, in das Ökosystem einzusteigen – und um den Aufwand für Implementierung, Migration und Wartung dieser alten APIs zu verringern.

Das Projektteam sieht Jakarta EE 9 vor allem als Tooling-Release:

  • Eine Plattform, für die Werkzeughersteller ihre Werkzeuge erstellen und aktualisieren können, um den neuen Namensraum jakarta.* zu unterstützen.
  • Eine Plattform, die Entwicklungsteams als stabiles Ziel für die Testmigration ihrer Anwendungen in den neuen Namensraum verwenden können.
  • Eine Plattform, die Laufzeitanbieter zum Testen und Bereitstellen von Optionen und Funktionen verwenden können, die die Migration und Rückwärtskompatibilität mit Jakarta EE 8 unterstützen.
  • Eine Grundlage für Innovationen, die Jakarta EE-Spezifikationsprojekte nutzen können, um neue Funktionen für die Veröffentlichung in Jakarta EE 10 und darüber hinaus voranzutreiben.

Für einzelne Spezifikationen, die zum Jakarta EE 9 Full Profile oder Web Profile gehören, werden die Spezifikationsdokumente von der Eclipse Foundation in den Jakarta-Namensraum konvertiert. Diese Spezifikationsdokumente werden als Teil des Jakarta EE 9 Release freigegeben.

Jakarta EE 9 wird keine Anforderungen an die Abwärtskompatibilität kompatibler Implementierungen zur Unterstützung der Jakarta EE 8-Version stellen. Kompatible Implementierungen des Jakarta EE 9 Web Profile und Full Profile müssen die Kompatibilität auf Java SE 11 bescheinigen.

Derzeit wurden der Java EE API-Code, die direkten Implementierungen dieser API und verschiedene unterstützende Bibliotheken (aus dem GlassFish-Projekt) sowie das TCK und alle bestehenden Probleme für diese beiden Projekte übernommen. Dies zusammengenommen ist eine immense Menge an Code, und es wurde eine riesige Menge Arbeit in die Übertragung gesteckt, aber das erlaubt es dem Team, das an der Veröffentlichung von Jakarta EE 9 arbeitet, einfach nicht, ein JSF 3.0 oder ein EE Security 1.1 zu veröffentlichen. Aber einige Projekte haben tatsächlich damit begonnen, auf ihre nächste größere API-Version hinzuarbeiten. Ich werde mich auf JSF 3.0 und JAX-RS 2.2 konzentrieren. Diese sind vorläufige Ideen, da weitere Beiträge von Anbietern und der Entwicklergemeinde erforderlich sind.

JSF 3.0

Die Arbeit für JSF 3.0 begann vor einiger Zeit im master-Branch des EE4J Mojarra-Projekts. JSF 3.0 wird in erster Linie einen Teil der alten Verkrustung beseitigen, die sich im Laufe der Jahre aufgebaut hat und die wegen der strengen Anforderungen an die Abwärtskompatibilität beibehalten wurde. Dazu gehört z. B. die Unterstützung der JSF-eigenen Ausdruckssprache sowie die Unterstützung für die Verwendung von JSP als Template-Engine für JSF (diese wurde 2009 mit der Veröffentlichung von JSF 2.0 effektiv veraltet). Besonders erwähnenswert ist, dass das JSF-eigene Managed-Bean-System, das selbst eine der Inspirationsquellen für CDI war, nun endlich vollständig entfernt wird, nachdem es seit JSF 2.0 schrittweise veraltet wurde. Das bedeutet also, dass JSF 3.0 nicht abwärtskompatibel sein wird, obwohl streng genommen nur die ältesten JSF 1.1-Anwendungen nicht mehr auf JSF 3.0 laufen wird. Die meisten modernen Anwendungen dürften keine großen Schwierigkeiten beim Upgrade haben.

Neben der Entfernung veralteter Dinge aus JSF, ist es geplant, JSF 3.0 auf dem Weg fortzusetzen, mehr eigene Artefakte nach CDI zu verschieben, was bereits in JSF 2.2 (FlowScope) und JSF 2.3 (viele JSF-Artefakte, die über CDI injiziert werden können) begonnen wurde.

JAX-RS 2.2

JAX-RS verwendet ein eigenes Dependency Injection-System auf Basis von @Context anstelle des @Inject von CDI. Obwohl JAX-RS im letzten Moment vor der ersten Veröffentlichung aktualisiert wurde, um ein gewisses Maß an Unterstützung für CDI zu bieten, hat die Tatsache, dass es sich bei den Ressourcen von JAX-RS nicht um CDI-Beans handelt, die Spezifikation unnötigerweise zurückgehalten und zu Verwirrung geführt, selbst seit JAX-RS in EE 6 (2009) eingeführt wurde.

Es ist daher geplant, JAX-RS stattdessen CDI verwenden zu lassen. Diese Umstellung auf CDI könnte möglicherweise in zwei Schritten erfolgen; in JAX-RS 2.2 sollte alles, was jetzt durch @Context injiziert werden kann, auch über @Inject injizierbar sein, und JAX-RS-Ressourcen wären standardmäßig CDI-Beans (sofern nicht ausdrücklich deaktiviert). Gleichzeitig würde @Context veraltet sein. In JAX-RS 3.0 würde @Context dann tatsächlich entfernt werden.

Jakarta EE ist die Zukunft von cloud-nativem Java. Die Open-Source-Software Jakarta EE treibt die native Cloud-Innovation voran, modernisiert Unternehmensanwendungen und schützt Investitionen in Java EE.

Zusammenfassend lässt sich sagen, dass Jakarta EE 8 eine neue Ära im Java-Ökosystem markiert. Es bringt das wichtige Java EE-Projekt unter einem Open-Source-Prozess zum Laufen und ebnet den Weg für notwendige Verbesserungen. Das Java-Ökosystem hat einen neuen Schwerpunkt auf Cloud Computing, und Jakarta EE ist der Schlüssel zu diesem Ansatz. Das Ziel von Jakarta EE ist die Beschleunigung der Entwicklung von Geschäftsanwendungen für Cloud Computing (cloud-native Anwendungen), wobei mit Spezifikationen gearbeitet wird, die von vielen Anbietern entwickelt wurden.

Short URL for this post: https://wp.me/p4nxik-3Hr
This entry was posted in Java EE and tagged . Bookmark the permalink.

Leave a Reply