Kolumne: EE Insights

Jakarta EE nimmt langsam Formen an: Glassfish 5.1, javax.* & Projektstrukturen

Christian Kaltepoth

Viel tut sich momentan bei der Java Enterprise Edition: der Umzug nach Eclipse, die Umbenennung in Jakarta EE, der neue Community-getriebene Prozess, die Konsolidierung und Weiterentwicklung der Standards. In der neuen Kolumne „EE Insights“ hält uns Christian Kaltepoth auf dem Laufenden und versorgt uns mit Insider-Wissen aus dem Jakarta-EE-Universum.

Christian Kaltepoth

Am 29. Januar 2019 war es endlich soweit. Die Eclipse Foundation gab die Veröffentlichung von Eclipse Glassfish 5.1.0 bekannt. Auf diesen Zeitpunkt hat die Jakarta EE Community lange warten müssen. Schließlich begann der Transfer der Java-EE-Projekte zur Eclipse Foundation bereits vor knapp anderthalb Jahren. Ursprünglich war das Release von Eclipse Glassfish sogar für den Dezember letzten Jahres geplant, musste dann aber aufgrund diverser Probleme mit dem doch recht engen Zeitplan verschoben worden. Aber was lange währt, wird endlich gut. Obwohl es mit dem anfänglich gesetzten Terminziel nicht ganz geklappt hat, kann die Jakarta EE Community doch sehr stolz auf diesen wichtigen Meilenstein sein.

Glassfish 5.1: Ein Meilenstein für Jakarta EE

Aber warum ist die Veröffentlichung von Eclipse Glassfish ein so wichtiger Schritt? Liest man die diversen Blog-Einträge zu diesem Release, erfährt man schnell, dass Eclipse Glassfish 5.1 eigentlich funktional dem Stand von Glassfish 5.0 entspricht. Und diese Version wurde von Oracle ja bereits im September 2017 veröffentlicht. Die wirklich wesentlichen Änderungen sind allerdings nicht funktionaler, sondern eher organisatorischer Natur.

Der wichtigste Aspekt dieses Meilensteins ist sicherlich, dass es sich bei diesem Release um einen vollständigen Java-EE-8-Applikationsserver handelt, der aus den von Oracle zur Eclipse Foundation transferierten Komponenten besteht. Jedes der knapp 40 Projekte hat somit eine funktionierende Projektinfrastruktur, hat das erste Release Review bestanden und alle Komponenten wurden erfolgreich in Eclipse Glassfish integriert. Eclipse Glassfish 5.1 hat dabei die Kompatibilität mit Java EE 8 durch das Bestehen der CTS-Tests bewiesen. In der Summe besteht die Java EE Test Suite aus über 52.000 Tests mit einer Gesamtlaufzeit von mehr als 98 Stunden. Durch diese beeindruckenden Zahlen wird umso mehr deutlich, welche Signifikanz dieses Release hat, und dass doch eine ganze Menge Arbeit dahinter steckt.

Wie bereits angedeutet, unterscheidet sich Eclipse Glassfish 5.1 vom Funktionsumfang her nicht von seinem Vorgänger. Allerdings gibt es doch einige wichtige Unterschiede, wie beispielsweise die Lizenz. Eclipse Glassfish verwendet die Eclipse Public License 2.0 (EPL2) und die GPL 2.0 mit der “GNU Classpath Exception”. Im Gegensatz dazu setzte Glassfish 5.0 noch auf die von Sun Microsystems stammende CDDL-Lizenz.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: 30+ Seiten Java-Wissen von Experten

Sie finden Artikel zu EnterpriseTales, Microservices, Req4Arcs, Java Core und Angular-Abenteuer von Experten wie Uwe Friedrichsen (codecentric AG), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

 

Um den Unterschied zwischen Java EE und Jakarta EE klarer zu machen, wurden außerdem die API-Artefakte unter einer neuen Maven Group ID veröffentlicht. Statt javax.* sollte man also zukünftig die Group ID jakarta.* verwenden, um Jakarta-EE-Artefakte zu referenzieren. Das Servlet API kann beispielsweise ab jetzt über die Maven-Koordinaten jakarta.servlet:jakarta.servlet-api bezogen werden. Während diese Änderung bei den APIs konsistent umgesetzt wurde, ergibt sich bei den Implementierungen ein gemischtes Bild. Die meisten Projekte sind bei der Group ID org.glassfish.* geblieben und einige wenige haben bereits auf org.eclipse.* gewechselt.

Die nächsten Schritte

Und was sind die nächsten Schritte? Aktuell implementiert Eclipse Glassfish den Java-EE-8-Standard. Das soll sich aber bald ändern. Der nächste Meilenstein wäre die Veröffentlichung von Jakarta EE 8 nach den Regeln des neuen Spezifikationsprozesses. Auch hier wird die erste Version vermutlich funktional identisch mit Java EE 8 sein, sodass erst in der darauf folgenden Version Neuerungen im API zu erwarten sind.

Damit die Arbeit am nächsten Meilenstein von Jakarta EE richtig losgehen kann, ist aber noch eine wesentliche Voraussetzung nötig. Zwar sind die API-Projekte, die Referenzimplementierungen und das Java EE TCK bereits zur Eclipse Foundation umgezogen, jedoch steht die Übertragung der Spezifikationsdokumente noch aus. Dieser Umstand wird besonders für die API-Projekte immer mehr zum Problem, die bereits aktiv an Funktionen für die nächste Version arbeiten. Das JAX-RS-Team hat beispielsweise schon sehr früh mit der aktiven Arbeit an neuen Funktionen begonnen und sich bereits auf das neue Java SE Bootstrapping API geeinigt. Allerdings war es hier noch immer nicht möglich, die neuen Funktionen in den Spezifikationsdokumenten zu dokumentieren. Das ist zwar aktuell noch kein allzu großes Problem, kommen aber noch mehr ausstehende Änderungen hinzu, wird es mit der Zeit immer schwieriger produktiv weiterzuarbeiten.

It’s all about the javax.*

Der Grund für die fehlenden Dokumente ist die Tatsache, dass die Vertragsverhandlungen zwischen Oracle und der Eclipse Foundation immer noch nicht abgeschlossen sind. Für die Spezifikationsdokumente ist vor allem noch die Übertragung des geistigen Eigentums zu klären. Zwar hat für die im Rahmen des JCP erarbeiteten Technologien der Specification Lead, also Oracle, weitgehende Rechte an der entstandenen Spezifikationen, jedoch haben auch die in der Expert Group vertretenen Parteien in der Regel geistiges Eigentum beigesteuert, was die Lage komplizierter macht. Es ist aber zu erwarten, dass diesbezüglich bald eine Einigung erzielt wird.

Ein weiterer Aspekt, der ebenfalls noch vertraglich zwischen der Eclipse Foundation und Oracle geklärt werden muss, ist die Nutzung des Java Trademarks. Hier ist vor allem auch die zukünftige Nutzung des Package Namespaces javax.* mit eingeschlossen. Das letzte Sitzungsprotokoll des Jakarta EE Steering Committee vom 15. Januar 2019 erlaubt einen Einblick in den aktuellen Stand der Verhandlungen. So hätte der erste Vertragsentwurf zwar die Nutzung des Java Trademarks weitgehend ermöglicht, allerdings hätte Oracle in dieser Variante auch weitgehenden Einfluss in den zukünftigen Spezifikationsprozess erhalten, was für die Eclipse Foundation für nicht akzeptabel gilt. Inzwischen wird eine alternative Version der Vertragsdokumente erarbeitet, mit der zwar die existierenden Spezifikationen auch weiterhin den Package Namespace javax.* verwenden dürfen, allerdings der Name „Java“ und einige der J-Akronyme in den Titeln der Spezifikationen nicht mehr erlaubt sein werden. Die Details hierzu werden aktuell noch verhandelt, sodass man auf die Veröffentlichung der nächsten Sitzungsprotokolle sehr gespannt sein darf.

Strukturelles

Ein weiteres stark diskutiertes Thema ist die zukünftige Struktur des Top-Level-Projektes Eclipse EE4J. Aktuell sind alle ehemaligen Java-EE-Spezifikationen, deren Referenzimplementierungen und das TCK als Unterprojekte des Top-Level-Projektes Eclipse EE4J organisiert. Diese Struktur hat vor allem zur Folge, dass es für alle Projekte ein einzelnes Project Management Committee (PMC) gibt. Das kann auf lange Sicht natürlich nur sehr eingeschränkt funktionieren, insbesondere, wenn man die doch große Menge von Projekten betrachtet, für das das PMC zuständig ist.

Eine Möglichkeit, diese Situation zu entspannen, wäre beispielsweise, das Eclipse-EE4J-Projekt aufzuteilen. Denkbar wäre etwa die Schaffung eines Jakarta-EE- und eines separaten Eclipse-Glassfish-Top-Level-Projektes. Die Teilung in Spezifikations- und Implementierungsprojekte liegt hier nahe und macht so auch sicherlich Sinn. Besonders, da der zukünftige Jakarta-EE-Spezifikationsprozess keine speziellen Referenzimplementierungen mehr kennt und es nur noch um “kompatible Implementierungen” geht, von denen Eclipse Glassfish eine von vielen ist. Ob es wirklich zu dieser Aufteilung kommt, steht allerdings noch nicht fest.

Wie man sieht, ist die Jakarta EE Community auch nach dem Release von Eclipse Glassfish weiter aktiv daran, die Zukunft von Enterprise Java zu definieren. Man darf also sehr gespannt sein, was in den nächsten Wochen und Monaten passiert.

Geschrieben von
Christian Kaltepoth
Christian Kaltepoth
Christian Kaltepoth arbeitet als Senior Developer bei ingenit GmbH & Co. KG in Dortmund. Sein Schwerpunkt ist die Entwicklung von webbasierten Unternehmensanwendungen auf Basis von Java-EE-Technologien. Darüber hinaus ist er in mehreren Open-Source-Projekten wie Apache DeltaSpike, Rewrite, PrettyFaces und Togglz aktiv. Er ist Mitglied der JSR 371 Expert Group und ein regelmäßiger Sprecher auf Konferenzen.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Jakarta EE nimmt langsam Formen an: Glassfish 5.1, javax.* & Projektstrukturen"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

Hi, weiss man schon wann Jakarta EE auch was Neues einführt? Denn man hat jetzt wieder ca. 1,5 Jahre Stillstand. Und da gibt es einige Dinge, die mal eine größere Überarbeitung bräuchten, IMHO.

Grüße