Kolumne: EE Insights

Jakarta EE 9: Ein erster Milestone und ein neues Release-Datum

Christian Kaltepoth

Der Juni ist zu Ende gegangen. Nachdem die Corona-Pandemie den Frühling dieses Jahres doch ziemlich durcheinander gebracht hat, kehrt langsam wieder zumindest ein wenig Normalität in den Alltag ein. Auch wenn es sicherlich kein “normaler” Sommer werden wird, da die Krise noch lange nicht überstanden ist. Aber Moment! Juni? War für Mitte Juni nicht das Release von Jakarta EE 9 geplant?

Aber fangen wir lieber weiter vorne an. Nach dem ersten offiziellen Release von Jakarta EE im September letzten Jahres, hat sich die Jakarta EE Community nur eine kurzer Verschnaufpause gegönnt. Mit Jakarta EE 9 plante man nun endlich den großen Befreiungsschlag, um die Plattform in Zukunft ohne irgendwelche Einschränkungen weiterentwickeln zu können. Konkret geht es dabei vor allem um die javax-Paketnamen, welche aus rechtlichen Gründen für die Weiterentwicklung nicht mehr genutzt werden dürfen. Mit der Tatsache, dass eine Migration der Paketnamen unausweichlich ist, hat sich die Community bereits im letzten Jahr abfinden müssen. Und da dieses Unterfangen eine beispiellose Herausforderung für die gesamte Javawelt sein wird, steht Jakarta EE 9 ganz im Zeichen dieser Umstellung. So wurde im Anfang des Jahres verabschiedeten Release-Plan festgelegt, dass lediglich die Migrationen auf die neuen jakarta-Paketnamen und keine weiteren Änderungen an der Plattform für Jakarta EE 9 geplant sind. Das finale Release sollte im Juni veröffentlicht werden.

Im Vergleich zu den für Java EE typischen Release-Zyklen war dieser doch recht „sportliche“ Zeitplan sehr positiv aufgenommen worden. Schließlich waren häufigere Veröffentlichungen neuer Versionen der Plattform eines der erklärten Ziele von Jakarta EE. Trotzdem war schon damals klar, dass es sehr knapp werden würde. Schließlich war abzusehen, dass die Anpassungen der APIs und Implementierungen, die Aktualisierungen der Spezifikationsdokumente und die Umsetzung der notwendigen Änderungen am Jakarta EE TCK ihre Zeit benötigen würden. Spätestens als klar wurde, dass es nicht alle Spezifikationen schaffen würden, wie ursprünglich geplant, im Februar erste Versionen der angepassten APIs bereitzustellen, war abzusehen, dass der Zeitplan doch ein wenig zu optimistisch war. Vermutlich hat aber auch die weltweite Pandemie dazu beigetragen, dass viele Freiwillige nicht in dem Maße Zeit in Jakarta EE investieren konnten, wie sie es eigentlich gerne getan hätten.

Jakarta EE 9: Der erste Meilenstein ist erreicht

Obwohl es mit dem finalen Release im Juni leider nicht geklappt hat, so hat Jakarta EE mit der Veröffentlichung eines ersten Milestones vorletzte Woche doch gezeigt, dass man enorme Fortschritte gemacht hat. Alle Spezifikationen haben inzwischen erste Versionen ihrer APIs veröffentlicht, die vollständig die neuen jakarta-Paketnamen nutzen. In einigen Fällen waren zudem Anpassungen an XML-Schemata und ähnlichen Artefakten notwendig. Die Verfügbarkeit der neuen APIs ist natürlich eine ganz wesentliche Voraussetzung für alle weiteren Migrationsschritte, vor allem für die Anpassungen der Implementierungsprojekte und des Jakarta EE TCKs. Auch in diesen Bereichen ist man gut vorangekommen. Die besonders für Eclipse Glassfish wichtigen Implementierungsprojekte, wie beispielsweise Eclipse Jersey und Eclipse Mojarra, haben erste Meilensteine veröffentlicht, welche den neuen Paketnamen unterstützen. Und mit Eclipse Glassfish 6.0.0 Milestone 1 existiert auch eine Vorabversion einer Jakarta-EE-9-Variante des bekannten Anwendungsservers.

Besonders erfreulich ist, dass nicht nur bei der Eclipse Foundation enorme Fortschritte bei der Migration auf den neuen jakarta-Namensraum gemacht werden. Inzwischen gibt es eine ganze Reihe von Produkten, die bereits Meilensteine für eine Jakarta-EE-9-Version veröffentlicht haben. Dazu zählen unter anderem Apache Tomcat, OpenLiberty, Apache TomEE und Piranha Micro. Auch Milestones von Payara und Wildfly sind bereits geplant und werden spätestens im Herbst erwartet.

Die Tatsache, dass bereits Milestones von Spezifikationen und Anwendungsservern existieren, bedeutet natürlich auch, dass Anwender theoretisch erste Experimente mit der Migration der eigenen Projekte auf Jakarta EE 9 durchführen könnten. Für viele Anwendungen könnte diese Anpassung relativ leicht sein. Mit einem „Suchen & Ersetzen“ der Paketnamen und XML-Namespaces ist der erste Teil der Migration schnell durchgeführt. Spannender wird es allerdings, wenn es um Bibliotheken und Frameworks geht. Da in vielen Fällen die Jakarta-EE-Plattform allerdings schon all das mitbringt, was man für die Entwicklung benötigt, besteht zumindest die Hoffnung, dass viele Anwendungen ohne große Mengen von zusätzlichen Abhängigkeiten auskommen, die zumindest potenziell bei einer Migration Probleme bereiten könnten. Und trifft man doch einmal auf eine Bibliothek, die lediglich den alten javax-Namespace unterstützt, wäre jetzt der perfekte Zeitpunkt, das Thema der Migration auf die neuen Paketnamen beim entsprechenden Projektteam einmal anzusprechen.

Noch einige Baustellen

Man sieht also sehr gut, dass Jakarta EE 9 auf einem guten Weg ist. Natürlich gibt es bis zum finalen Release aber noch einiges zu tun. So sind beispielsweise viele der Spezifikationsdokumente noch in Arbeit. Das liegt vor allem daran, dass die Dokumente aus rechtlichen Gründen erst sehr spät zugänglich gemacht wurden und somit auch erst sehr spät mit den notwendigen Anpassungen begonnen werden konnte. Und oft sind es auch rein technische Probleme, welche die Fertigstellung der Dokumente verzögern. Zu Zeiten von Java EE wurden die Dokumente üblicherweise mit LaTeX oder kommerziellen Tools wie FrameMaker geschrieben. Schon sehr früh entschied sich die Jakarta EE Community, zukünftig AsciiDoc als Format zu verwenden, welches in der Java-Welt einen sehr guten Ruf hat und daher auch häufig Anwendung findet. Glücklicherweise wurden die Dokumente bereits vor der Übergabe an die zuständigen Spezifikationsprojekte ins AsciiDoc-Format konvertiert. Wie man sich allerdings denken kann, ist eine automatische Konvertierung zwischen verschiedenen Dokumentformaten nicht immer problemlos möglich. Daher kämpfen einige der Spezifikationen bis heute damit, die durch die automatisierte Konvertierung entstandenen Fehler zu korrigieren. Da Formatierungsprobleme oft im Detail stecken und einige der Dokumente viele Hundert Seiten stark sind, handelt es sich hier natürlich um eine mühselige und aufwendige Aufgabe.

Die anderen beiden großen Baustellen sind die Implementierungsprojekte und das Jakarta EE TCK. Die Veröffentlichung der Milestones zeigen hier, dass zwar Fortschritte gemacht wurden, aber auch, dass noch viel Arbeit bevorsteht. Für beide gilt, dass die Migration der Paketnamen zwar theoretisch mit einem einfachen Ersetzen der Paketnamen erledigt ist, aber in der Praxis doch deutlich aufwendiger sein kann. Beim TCK kommt noch dazu, dass für Jakarta EE 9 einige wenige Spezifikationen aus der Plattform entfernt wurden. Zwar konnte man hierdurch den Migrationsaufwand für veraltete Teile der Plattform einsparen, die eh kaum mehr eine Relevanz in der Praxis haben, allerdings sorgt das beim TCK für Zusatzaufwand, da die betroffenen Teile des TCKs sauber entfernt werden müssen.

Positive Enttäuschung

Trotzdem ist es natürlich etwas enttäuschend, dass der ursprünglich anvisierte Zeitplan nicht eingehalten werden konnte. Wie bereits angedeutet, sind die Gründe dafür vielfältig. Und zu optimistische Zeitplanung ist schließlich besonders in der IT ein oft auftretendes Problem, das jeder aus seiner beruflichen Praxis gut kennt. Meiner Meinung nach ist einer der bereits genannten Gründe für den Zeitverzug aber auf einen eigentlich eher positiv zu bewertenden Aspekt zurückzuführen.

In einem Blogbeitrag zur Veröffentlichung des Meilensteins von Jakarta EE 9 führt Mike Milinkovich, der geschäftsführende Direktor der Eclipse Foundation, einige interessante Statistiken auf, die Rückschlüsse darauf zu lassen, wer sich in welchem Umfang an der Entwicklung von Jakarta EE beteiligt. Hier fällt vor allem auf, dass über 40% der Commits von unabhängigen Unterstützern oder von Committern stammen, die zu keiner „Member Company“ der Eclipse Foundation gehören. Oracle ist mit 27% immer noch stark vertreten und sehr aktiv. Dies ist vor allem deshalb erfreulich, weil immer wieder gemutmaßt wurde, dass sich Oracle aus der aktiven Arbeit an Jakarta EE zurückziehen will. Bei Red Hat, Payara, VMware und IBM sind es dagegen jeweils unter 9%.

Natürlich kann aus den reinen Commits nicht auf die gesamte Arbeitsverteilung geschlossen werden und ist damit eher als Indiz zu verstehen. Trotzdem ist ein Anteil von 40% für Beiträge aus der Community natürlich extrem beeindruckend. Vor allem, da es sich oft auch um rein ehrenamtliche Arbeit handeln dürfte, die außerhalb der eigenen Arbeitszeit investiert wird. Und in Zeiten einer weltweiten Pandemie, geschlossenen Schulen und bedrohten Jobs ist für dieses Engagement nicht immer genug Zeit. Aus meiner Sicht könnte das daher zumindest einer der Gründe für die Verspätung von Jakarta EE 9 sein.

16. September als Release-Datum?

Und wie geht es nun weiter? Zwar ist es im Juni nur ein Meilenstein, statt des ursprünglich geplanten finalen Releases geworden, aber Jakarta EE befindet sich auf einem guten Weg. Der angepasste Zeitplan sieht das finale Release nun für den 16. September vor. Und dieses Datum ist nicht zufällig gewählt. Zum einen ist die Veröffentlichung somit knapp eine Woche vor der Oracle Code One Konferenz geplant, dem Nachfolger der JavaOne, die dieses Jahr aus gegebenem Anlass virtuell stattfinden wird. Zum anderen wäre das Timing auch aus einem anderen Grund günstig. Schließlich ist im September 2019 Jakarta EE 8 erschienen und man würde sich somit an das zwischenzeitlich formulierte Ziel halten, mindestens einmal im Jahr eine neues Jakarta EE Release herauszubringen.

Bezüglich des angepassten Zeitplans darf man auf jeden Fall vorsichtig optimistisch sein. Auch wenn die TODO-Liste für Jakarta EE 9 noch lange nicht leer ist, so geht man doch auf bisher Geleistetes stolz sein und motiviert in den Endspurt starten.

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

avatar
4000
  Subscribe  
Benachrichtige mich zu: