Jakarta EE ist der neue alte Enterprise Java Standard. Dieser ermöglicht es, langfristige Enterprise-Projekte zu realisieren, weil er Investistionssicherheit durch Abwärtskompatibilität und klare Migrationspfade sicherstellt. Ein Artikel von Arne Limburg.
Große Software-Projekte benötigen in der Regel nicht nur eine lange Zeit, um sie umzusetzen. Einmal fertiggestellt, läuft die Software häufig viele Jahre oder sogar Jahrzehnte. Die initial verwendeten Technologien veralten dabei leider sehr schnell.
Um sicherzugehen, dass alte Software mit aktuellen Technologien weiterhin lauffähig ist oder sogar regelmäßig auf einen aktuellen Stand gebracht werden kann, muss eine zukunftsfähige Technologie ausgewählt werden, von der klar ist, dass sie auch in der weiter entfernten Zukunft (also ein Zeitraum von zehn oder zwanzig Jahren) noch existiert oder durch eine gleichwertige Technologie mit klaren Migrationspfaden ersetzt werden kann.
Insbesondere, um die Investition in die Software abzusichern, setzen Unternehmen daher auf Standards. Ein weit verbreiteter Standard, der diese Investitionssicherheit verspricht, ist seit jeher der Enterprise Java Standard.
Die ersten Versionen von Java EE (damals hieß es noch J2EE) erhielten zu Recht den Ruf schwergewichtig zu sein. Nicht ohne Grund etablierten sich zu dieser Zeit alternative Java Enterprise Frameworks wie das Springframework.
Die erste Änderung änderte sich aber mit der Version Java EE 5 durch die Einführung von Annotations statt XML und das Ersetzen von Entity Beans durch den JPA Standard.
Richtig Fahrt nahm Java EE mit den Versionen 6 und 7 auf, als mit CDI ein leichtgewichtiges Komponenten-Modell eingeführt wurde und nach und nach immer mehr Spezifikationen neben EJB auch CDI als Komponenten-Modell unterstützen. Als ein Beispiel sei hier die JTA-Specification (für Transaktionen) genannt, die neben @TransactionAttribute für EJBauch @Transactional für CDI einführte.
Erste Ängste, dass die Entwicklung von Java EE zu sehr an einem Unternehmen hängen könnte und im Grunde gar nicht unabhängig möglich sei, kamen auf, als 2010 Oracle den Besitzer von Java (nämlich Sun Microsystems) übernahm.
Zunächst schienen diese Ängste unbegründet, wie besagte Entwicklung von Java EE 6 und 7 zeigte. Während der Entwicklung von Java EE 8 aber kam der Bruch. Oracle stellte 2015 ohne Angaben von Gründen die Arbeit an dem Standard ein. In den verschiedenen Spezifizierungs-Komitees saßen und sitzen zwar auch Personen aus anderen Unternehmen, bei den meisten Spezifikationen wurde zu jener Zeit der Spec-Lead allerdings von Oracle gestellt.
Es zeigte sich, dass ohne die Tätigkeit der Spec-Leads wenig Bewegung in den Spezifikationen war.
Diese Tatsache war aber gewissermaßen die Feuertaufe für Java EE. Es dauerte zwar etwas, bis die Community bemerkte, dass Oracle das Interesse an Java EE zu verlieren schien, dann aber formierte sich Widerstand. Dabei erwies es sich als Vorteil, dass der Java-EE-Standard aus mehreren (mehr oder weniger) unabhängigen Teilen bestand. Einerseits bildeten sich Gruppen von Freiwilligen, die die einzelnen Teilstandards unabhängig von Oracle weiterentwickeln wollten. Andererseits können diese Teile des Standards auch einzeln verwendet werden. Das Spring Framework machte dieses Vorgehen seit Jahren vor. Dort werden immer wieder einzelne Standards aus Java EE eingebunden und können verwendet werden.
Die vielen Initiativen, die sich gerade in dieser Zeit bildeten, in der Oracle nicht mehr aktiv an Java EE arbeitete, demonstrierten die Zukunftsfähigkeit eindrucksvoll.
In dieser Zeit entstand auch das Microprofile. Auch dieses startete zunächst als ein Bündel bestehender Java EE Spezifikationen wie CDI, JAX-RS und JSON-P. Ziel war es, eine Spezifikation zu schaffen, mit der Anwendungen für Microservice-Architekturen und die Cloud geschrieben werden konnten. Die Namensähnlichkeit mit einem Konzept aus Java EE – den Profilen – von denen das erste in Java EE 6 das Web-Profile war, ist sicherlich nicht zufällig.
Dass das Microprofile unabhängig von Java EE und damit unabhängig von Oracle entwickelt wurde, hatte einen großen Vorteil. Java EE hat im Laufe der Zeit viele Altlasten angesammelt, meistens in Form von Spezifikationen, die nicht mehr praxisrelevant sind. Aufgrund der Forderung nach Abwärtskompatibilität konnten diese aber schwer entfernt werden. Das Microprofile braucht darauf keine Rücksicht zu nehmen. Umgekehrt können aber Spezifikationen aus dem Microprofile ohne Probleme in Java EE übernommen werden.
Nach einem Jahr der Untätigkeit verkündete Oracle auf der JavaOne 2016, dass die Arbeit an Java EE 8 wieder aufgenommen werden sollte. Kurze Zeit später gab es eine weitere Überraschung: Oracle plante, Java EE inklusive aller Sourcen (Referenzimplementierungen und Test-Suiten) an eine Open-Source-Community zu übergeben. Die Wahl fiel dabei auf die Eclipse-Foundation.
Die Übergabe gestaltete sich etwas schwierig, weil Oracle die Namensrechte an Java und Java EE behalten wollte. Die Lösung war am Ende eine Umbenennung. Dabei fiel die Wahl auf den Namen Jakarta EE. Der Name Jakarta wurde dabei freundlicher Weise von der Apache Foundation zur Verfügung gestellt.
So wurde die Version Java EE 8 unter dem Dach der Eclipse-Foundation erneut unter dem Namen Jakarte EE 8 veröffentlicht. Die beiden Versionen sind technologisch identisch.
Die Umbenennung der verwendeten Packages von javax.enterprise nach jakarta.enterprise erfolgte dann erst mit der Version Jakarta EE 9. Um Benutzern den Umstieg zu erleichtern, entschied man sich bewusst dazu, auch mit diesem Release keine technischen Neuerungen zu veröffentlichen, sondern lediglich die Umbenennung vorzunehmen.
Immerhin wurde recht schnell das Release 9.1 hinterhergeschoben, mit dem zumindest ein Update auf Java 11 mit kleineren Anpassungen (z.B. Unterstützung für repeatable Annotations) erfolgen.
Das erste Release unter dem Dach der Eclipse-Foundation, das mit echten neuen Features daherkommt, ist Jakarta EE 10.
Jakarta EE hat eine bewegte Geschichte hinter sich. An ihr zeigt sich aber, wie ein Standard mit klar definierten Aktualisierungsregeln und klaren Migrationspfaden aktuell bleiben, bzw. immer wieder aktuell werden kann. Die Reaktionen auf die Unsicherheit, ob und wie Oracle Java EE weiterentwickeln würde, haben darüber hinaus gezeigt, welchen großen Wert die starke JEE-Community hat und dass auch sie dazu beiträgt, die Zukunftssicherheit von JEE zu garantieren.
Seit der Übergabe an die Eclipse Foundation und der Umbenennung auf Jakarta EE beteiligt sich diese Community auch mehr denn je an der Weiterentwicklung des Standards.
Große Software-Projekte benötigen in der Regel nicht nur eine lange Zeit, um sie umzusetzen. Einmal fertiggestellt, läuft die Software häufig viele Jahre oder sogar Jahrzehnte. Die initial verwendeten Technologien veralten dabei leider sehr schnell.
Um sicherzugehen, dass alte Software mit aktuellen Technologien weiterhin lauffähig ist oder sogar regelmäßig auf einen aktuellen Stand gebracht werden kann, muss eine zukunftsfähige Technologie ausgewählt werden, von der klar ist, dass sie auch in der weiter entfernten Zukunft (also ein Zeitraum von zehn oder zwanzig Jahren) noch existiert oder durch eine gleichwertige Technologie mit klaren Migrationspfaden ersetzt werden kann.
Insbesondere, um die Investition in die Software abzusichern, setzen Unternehmen daher auf Standards. Ein weit verbreiteter Standard, der diese Investitionssicherheit verspricht, ist seit jeher der Enterprise Java Standard.
Die ersten Versionen von Java EE (damals hieß es noch J2EE) erhielten zu Recht den Ruf schwergewichtig zu sein. Nicht ohne Grund etablierten sich zu dieser Zeit alternative Java Enterprise Frameworks wie das Springframework.
Die erste Änderung änderte sich aber mit der Version Java EE 5 durch die Einführung von Annotations statt XML und das Ersetzen von Entity Beans durch den JPA Standard.
Richtig Fahrt nahm Java EE mit den Versionen 6 und 7 auf, als mit CDI ein leichtgewichtiges Komponenten-Modell eingeführt wurde und nach und nach immer mehr Spezifikationen neben EJB auch CDI als Komponenten-Modell unterstützen. Als ein Beispiel sei hier die JTA-Specification (für Transaktionen) genannt, die neben @TransactionAttribute für EJBauch @Transactional für CDI einführte.
Erste Ängste, dass die Entwicklung von Java EE zu sehr an einem Unternehmen hängen könnte und im Grunde gar nicht unabhängig möglich sei, kamen auf, als 2010 Oracle den Besitzer von Java (nämlich Sun Microsystems) übernahm.
Zunächst schienen diese Ängste unbegründet, wie besagte Entwicklung von Java EE 6 und 7 zeigte. Während der Entwicklung von Java EE 8 aber kam der Bruch. Oracle stellte 2015 ohne Angaben von Gründen die Arbeit an dem Standard ein. In den verschiedenen Spezifizierungs-Komitees saßen und sitzen zwar auch Personen aus anderen Unternehmen, bei den meisten Spezifikationen wurde zu jener Zeit der Spec-Lead allerdings von Oracle gestellt.
Es zeigte sich, dass ohne die Tätigkeit der Spec-Leads wenig Bewegung in den Spezifikationen war.
Diese Tatsache war aber gewissermaßen die Feuertaufe für Java EE. Es dauerte zwar etwas, bis die Community bemerkte, dass Oracle das Interesse an Java EE zu verlieren schien, dann aber formierte sich Widerstand. Dabei erwies es sich als Vorteil, dass der Java-EE-Standard aus mehreren (mehr oder weniger) unabhängigen Teilen bestand. Einerseits bildeten sich Gruppen von Freiwilligen, die die einzelnen Teilstandards unabhängig von Oracle weiterentwickeln wollten. Andererseits können diese Teile des Standards auch einzeln verwendet werden. Das Spring Framework machte dieses Vorgehen seit Jahren vor. Dort werden immer wieder einzelne Standards aus Java EE eingebunden und können verwendet werden.
Die vielen Initiativen, die sich gerade in dieser Zeit bildeten, in der Oracle nicht mehr aktiv an Java EE arbeitete, demonstrierten die Zukunftsfähigkeit eindrucksvoll.
In dieser Zeit entstand auch das Microprofile. Auch dieses startete zunächst als ein Bündel bestehender Java EE Spezifikationen wie CDI, JAX-RS und JSON-P. Ziel war es, eine Spezifikation zu schaffen, mit der Anwendungen für Microservice-Architekturen und die Cloud geschrieben werden konnten. Die Namensähnlichkeit mit einem Konzept aus Java EE – den Profilen – von denen das erste in Java EE 6 das Web-Profile war, ist sicherlich nicht zufällig.
Dass das Microprofile unabhängig von Java EE und damit unabhängig von Oracle entwickelt wurde, hatte einen großen Vorteil. Java EE hat im Laufe der Zeit viele Altlasten angesammelt, meistens in Form von Spezifikationen, die nicht mehr praxisrelevant sind. Aufgrund der Forderung nach Abwärtskompatibilität konnten diese aber schwer entfernt werden. Das Microprofile braucht darauf keine Rücksicht zu nehmen. Umgekehrt können aber Spezifikationen aus dem Microprofile ohne Probleme in Java EE übernommen werden.
Nach einem Jahr der Untätigkeit verkündete Oracle auf der JavaOne 2016, dass die Arbeit an Java EE 8 wieder aufgenommen werden sollte. Kurze Zeit später gab es eine weitere Überraschung: Oracle plante, Java EE inklusive aller Sourcen (Referenzimplementierungen und Test-Suiten) an eine Open-Source-Community zu übergeben. Die Wahl fiel dabei auf die Eclipse-Foundation.
Die Übergabe gestaltete sich etwas schwierig, weil Oracle die Namensrechte an Java und Java EE behalten wollte. Die Lösung war am Ende eine Umbenennung. Dabei fiel die Wahl auf den Namen Jakarta EE. Der Name Jakarta wurde dabei freundlicher Weise von der Apache Foundation zur Verfügung gestellt.
So wurde die Version Java EE 8 unter dem Dach der Eclipse-Foundation erneut unter dem Namen Jakarte EE 8 veröffentlicht. Die beiden Versionen sind technologisch identisch.
Die Umbenennung der verwendeten Packages von javax.enterprise nach jakarta.enterprise erfolgte dann erst mit der Version Jakarta EE 9. Um Benutzern den Umstieg zu erleichtern, entschied man sich bewusst dazu, auch mit diesem Release keine technischen Neuerungen zu veröffentlichen, sondern lediglich die Umbenennung vorzunehmen.
Immerhin wurde recht schnell das Release 9.1 hinterhergeschoben, mit dem zumindest ein Update auf Java 11 mit kleineren Anpassungen (z.B. Unterstützung für repeatable Annotations) erfolgen.
Das erste Release unter dem Dach der Eclipse-Foundation, das mit echten neuen Features daherkommt, ist Jakarta EE 10.
Jakarta EE hat eine bewegte Geschichte hinter sich. An ihr zeigt sich aber, wie ein Standard mit klar definierten Aktualisierungsregeln und klaren Migrationspfaden aktuell bleiben, bzw. immer wieder aktuell werden kann. Die Reaktionen auf die Unsicherheit, ob und wie Oracle Java EE weiterentwickeln würde, haben darüber hinaus gezeigt, welchen großen Wert die starke JEE-Community hat und dass auch sie dazu beiträgt, die Zukunftssicherheit von JEE zu garantieren.
Seit der Übergabe an die Eclipse Foundation und der Umbenennung auf Jakarta EE beteiligt sich diese Community auch mehr denn je an der Weiterentwicklung des Standards.
