Jakarta EE 8: alles bleibt neu – zum Status quo von Enterprise Java

Inhaltsverzeichnis

Das erste Jakarta-EE-Release bringt keine neuen APIs mit sich, sondern lediglich eine vollständig herstellerneutrale und offene Version dessen, was bereits da war. Hinter den Kulissen hat sich aber einiges mehr getan.

Fast auf den Tag genau zwei Jahre, nachdem Oracle Java EE geöffnet und an die Eclipse Foundation übergeben hat, war es am 10. September endlich soweit: Jakarta EE 8, die erste vollständige Open-Source-Variante des Enterprise-Java-Standards, wurde veröffentlicht.

Was erwartet uns mit diesem Release? Eine zu 100 Prozent kompatible Version zu der bisher unter der Obhut von Oracle stehenden Java Enterprise Edition 8. Das ist nicht wirklich viel für zwei Jahre harter Arbeit, werden sich jetzt manche Leser sicherlich denken. Trotzdem stellt dieses Release einen der wohl wichtigsten Meilensteine in der mittlerweile 20-jährigen Geschichte der Java Enterprise Edition dar. Denn in den vergangenen 24 Monaten wurde in der Eclipse Foundation die Grundlage für eine offene, Community-getriebene Weiterentwicklung des Enterprise-Java-Standards in Richtung Cloud-native geschaffen und damit eine Zukunft für den bereits totgesagten Standard ermöglicht – nicht mehr und nicht weniger.

"Open Source Cloud Native Java: Powered by participation, Jakarta EE is focused on enabling community-driven collaboration and open innovation for the cloud”, heißt es entsprechend prominent auf der Startseite von Jakarte EE.

Natürlich verwundert gerade vor diesem Hintergrund ein wenig, dass sich im aktuellen Release keine neuen (Cloud-)APIs finden. Das hat seinen Grund.

Erst die Kompatibilität, dann die Erweiterungen

Dass Jakarta EE mit seinem ersten Release noch keine Innovationen mit sich bringen würde, war bereits sehr früh klar. In einem ersten Schritt wollte die Jakarta EE Working Group, in der sich neben der Eclipse Foundation auch Vertreter von Oracle, Fujitsu, IBM, Payara, Red Hat und Tomitribe finden, zunächst sicherstellen, dass Jakarta EE 8 vollständig kompatibel zum bisherigen Standard ist. Nur so kann gewährleistet werden, dass alle bisherigen Nutzer von Java EE ihre Anwendungen mit möglichst wenig Aufwand migrieren und so ihr bis dato getätigtes Investment sichern können. Ein Muss für die Akzeptanz innerhalb der Java-EE-Community.

Das alleine dieser Schritt schon einem erheblichen Kraftakt gleichkommt, zeigt ein Blick auf die Webseite von Jakarta EE 8. Insgesamt 43 Projekte mit mehr als 60 Millionen Zeilen Code mussten von Oracle zur Eclipse Foundation umziehen, um dort, ein wenig aufgeräumt, in eine eigene Build- und Deplyoment-Infrastruktur eingebettet und via Git-Repositories der Öffentlichkeit zur Verfügung gestellt zu werden. Neben den Spezifikationen der APIs selbst betrifft das vor allem die TCKs. Witzigerweise mussten auch alle Bugs beziehungsweise Issues übernommen werden, um eine 100-Prozent-Kompatibilität zu gewährleisten.

Das erste Jakarta-EE-Release bringt also keine neuen APIs mit sich, sondern lediglich eine vollständig herstellerneutrale und offene Version dessen, was bereits da war, hinter den Kulissen hat sich aber in den letzten zwei Jahren einiges mehr getan.

Ein Blick hinter die Kulissen

Alle Jakarta-EE 8-Spezifikationen wurden gemäß dem neu geschaffenen Jakarta EE Specification Process (JESP) beschrieben, welcher der Nachfolger des Java Community Process (JCP) ist. Auch wenn die Namen der Spezifikation im Rahmen der Migration sinnvollerweise vereinheitlicht wurden und somit dem Wildwuchs der vergangenen Jahre – JMS zum Beispiel ist ein Service, JTA dagegen eine API und JCA eine Architektur – ein Ende gesetzt wurde, sind sie inhaltlich kompatibel zu ihren Java-EE-8-Pendants. Das gilt sowohl für die APIs und Javadocs als auch für die verwendeten javax.*-Namespaces. Eine Ausnahme stellen lediglich die Oracle-Trademarks dar, die ausgetauscht werden.

Neben den Spezifikationen selbst wurden auch die zugehörigen TCKs migriert und als Jakarta EE 8 TCKs veröffentlicht (Eclipse Public Licence, EPL 2.0). Auch diese sind kompatibel zu den Java EE 8 TCKs.

Bereits Anfang des Jahres wurde Eclipse GlassFish 5.1 veröffentlicht und mit Java EE 8 zertifiziert. Während die Sourcen des Anwendungsservers zu diesem Zeitpunkt bereits bei der Eclipse Foundation lagen, liefen die Tests damals noch auf der Infrastruktur von Oracle. Zeitgleich mit der Veröffentlichung von Jakarta EE 8 durchlief Eclipse GlassFish 5.1 auch auf der eigenen Infrastruktur die TCKs und gilt somit nicht nur als Java-EE-8- sondern auch als Jakarta-EE-8-kompatibel (Full Platform und Web Profile). Eine Liste aller bereits heute kompatiblen Server findet sich unter "Jakarta EE 8 Compatible Products".

Was bringt die Zukunft?

Der ganze Aufwand der letzten zwei Jahre rechnet sich natürlich nur dann, wenn die Zukunftsvisionen der Eclipse Foundation auch realisiert werden. Wir erinnern uns: "Open Source Cloud Native Java". Laut Aussage der Open-Source-Organisation möchte man zukünftig deutlich schneller und regelmäßiger neue Releases veröffentlichen. Schaut man sich einmal die Releasezyklen des JDKs oder aber der ebenfalls in der Eclipse Foundation beheimateten MicroProfiles an, scheint das ein durchaus realistisches Ziel zu sein.

Zusätzlich möchte man die Einstiegshürde deutlich verringern. Das gilt sowohl für Hersteller von Application-Servern als auch für Unternehmen, Gruppen oder einzelne Personen, die den neuen Standard vorantreiben wollen. Ein erster wichtiger Schritt hierzu ist durch die Öffnung der TCKs sowie dank des neu geschaffenen Jakarta EE Speficication Process bereits getan.

Laut eigenen Angaben sollen neue Spezifikationen zukünftig vornehmlich nach dem "Code First"-Ansatz entstehen. Das heißt, APIs sollen sich erst einmal in der Praxis etablieren, bevor sie in eine Spezifikation gegossen werden. Eine in der Open-Source-Community gängige Praxis, die vor den aus der J2EE-Welt – und teilweise auch noch aus der Java-EE-Welt – nur zu gut bekannten, am Reißbrett entworfenen Elfenbeinturm-APIs schützten soll und darüber hinaus sicherlich die Akzeptanz in der Community für neue APIs erhöhen wird.

Eine Umfrage in der Community hat gezeigt, dass vor allem Cloud-native-Themen wie Microservices, Kubernetes und Services-Meshes (insbesondere Istio) kritisch für den zukünftigen Erfolg von Jakarta EE sein werden und daher Top-Kandidaten für neue Spezifikationen sind. Insbesondere in Hinblick auf die Unterstützung von Microservices ist davon auszugehen, dass neben der Spezifikation neuer APIs vor allem eine stärkere Annäherung an MicroProfile.io stattfinden wird. Das legt auch die Agenda der parallel zum Release von Jakarta EE stattgefundenen Online-Konferenz JakartaOne nahe, in der sich etliche Vorträge mit der gemeinsamen Verwendung von Jakarta EE 8 und MicroProfile 3 beschäftigt haben.

Das Problem mit den Trademarks

Bevor allerdings die nächsten Schritte angegangen werden können, muss zunächst noch ein "kleines" Problem aus der Welt geschaffen werden: Die Umbenennung aller Java-API-Packages von javax.* zu jakarta.*. Oracle hat zwar die weitere Verwendung des Package-Präfix javax gestattet, das aber nur dann, wenn die APIs unverändert bleiben. Neue APIs oder Änderungen (dies gilt übrigens auch für Bugfixes) an bestehenden APIs führen automatisch auch zu einem Verbot der Verwendung von javax.

Eine Diskussion darüber, ob es zukünftig immer dann zur Umbenennung kommen soll, wenn eine API angefasst wird oder alternativ alle Packages einmalig refaktorisiert werden sollen, hat eine klare Tendenz in Richtung Big Bang aufgezeigt. Man war sich ebenfalls einig darüber, dass lediglich ein Austausch von javax.* zu jakarta.* stattfinden soll, weitere Änderungen hinter dem Präfix aber zu unterlassen sind.

Entsprechend sieht es aktuell danach aus, dass auch das kommende Release Jakarta EE 9 weiterhin keine neuen APIs mit sich bringen wird, sondern lediglich die neuen Package-Strukturen realisiert. Bestehende Anwendungen, die zukünftig auf Jakarta EE 9 Servern laufen wollen, müssten also entsprechend umgestellt werden. Hierbei können die Refactoring-Tools der IDEs helfen. Alternativ könnten die Application-Server intern die alten Package-Namen auf die neuen mappen, sodass existierende Jakarta-8-Anwendungen ohne jeglichen Aufwand auch auf Jakarta 9+ lauffähig wären. Neben dem ganzen Voodoo, den Application-Server schon heute betreiben, kein wirkliches Hexenwerk.

Innovationen – nur wann?

Weiterhin ist davon auszugehen, dass nach GlassFish, OpenLiberty (IBM) und WildFly (Red Hat), auch andere Java-EE-8-Application-Server die Jakarta TCKs durchlaufen und sich somit Jakarta-EE-kompatibel nennen dürfen. Selbst Oracle hat bereits angekündigt, dass man mit Hochdruck an einer gleichzeitig mit Java EE 8 und Jakarta EE 8 kompatiblen Version des WebLogic Application Server arbeitet.

"We're extremely pleased that Jakarta EE 8 has been released. This represents the culmination of a great deal of work by the entire Jakarta EE community, including Oracle, and we appreciate everyone's contributions. Oracle is working on the delivery of a Java EE 8 and Jakarta EE 8 compatible WebLogic Server implementation…", so Tom Snyder, Vice President Oracle Software Development.

Die ersten wirklichen Innovationen in Richtung Cloud-native sind wahrscheinlich erst mit Jakarta EE 10 zu erwarten. In Zeiten des JCPs wäre das in fünf bis zehn Jahren gewesen. Die Eclipse Foundation schafft es hoffentlich in einem Zehntel der Zeit. Ein erster heißer Kandidat für eine neue API ist Jakarta NoSQL zur herstellerunabhängigen Anbindung und Nutzung von NoSQL-Datenbanken innerhalb von Jakarta-EE-Anwendungen.

Fazit

Es kommen spannende Zeiten auf uns zu. Zeiten, die über die Zukunft des Enterprise-Java-Standards entscheiden werden. Nach meiner persönlichen Erfahrungen mit der Eclipse Foundation (im Rahmen von MicroProfile.io) und der Enterprise-Java-Community bin ich sehr guter Hoffnung, dass diese Zeiten positiv sein werden. ()