Auf die Plätze, fertig, ...

Startschuss für Jakarta EE 8: Ein erster Schritt in Richtung Zukunft für Enterprise Java

Thilo Frotscher

© Shutterstock / Jacob Lund

Nach einer kleinen Ewigkeit ist es nun endlich soweit: Das lange erwartete erste Release von Jakarta EE wurde öffentlich vorgestellt. Nun darf die Community auf eine rasche Weiterentwicklung der Plattform hoffen. Thilo Frotscher fasst in diesem Artikel die wichtigsten Informationen zum ersten Release von Java EE unter dem Schirm der Eclipse Foundation zusammen.

Das erste Release des „neuen“ Java EE trägt den Namen „Jakarta EE 8“ und wurde am heutigen 10. September vorgestellt. Zur Feier des Tages können Entwickler einer virtuellen Online-Konferenz beiwohnen – es werden nicht weniger als 19 Beiträge von je einer Stunde Länge ins Netz gestreamt. Unter den Referenten finden sich zahlreiche international bekannte Java Enterprise Experten und sogar James Gosling, einer der Urväter von Java.

Jakarta EE 8 – dies soll der Name verdeutlichen – ist funktional identisch zu Java EE 8, dessen Veröffentlichung immerhin schon zwei Jahre zurückliegt. Somit könnte man denken, es wäre in der Zwischenzeit nicht viel geschehen. Tatsächlich aber war der Umzug der Java-EE-Plattform zur Eclipse Foundation mit erheblichen Anstrengungen verbunden. So waren etwa große Mengen an Code auf eine neue Build-Infrastruktur zu migrieren. Dies beinhaltet unter anderem auch die bisherige Referenzimplementierung „Glassfish“ sowie die fortan Open Source verfügbaren TCKs (Technology Compatibility Kits). Angeblich handelt es sich dabei insgesamt um ca. 5,5 Million Codezeilen und über 2,2 Million Kommentarzeilen in mehr als 61.000 Dateien. Dies wäre vergleichbar mit dem Backend von World of Warcraft und dem Linux Kernel 2.6.0. Es ist somit ein nicht zu unterschätzender Erfolg, wenn nun mit dem Release von Eclipse Glassfish 5.1 ein zu Java EE 8 kompatibler Application Server auf der Infrastruktur der Eclipse Foundation gebaut und seine Kompatibilität mit Hilfe der TCKs nachgewiesen werden konnte.

Doch damit nicht genug. Hinter den Kulissen wurden darüber hinaus schwierige juristische Verhandlungen geführt und insbesondere Marken- und Nutzungsrechte verhandelt. Die Spezifikationsdokumente der einzelnen Java-EE-Technologien wurden zur Eclipse Foundation übertragen. Und ein neuer Spezifikationsprozess namens EFSP (Eclipse Foundation Specification Process) wurde verabschiedet, welcher künftig den JCP ersetzen soll. Der EFSP sieht unter anderem vor, dass es künftig keine so genannten Spec Leads mehr geben soll und neue Features in einem „Code-First“-Ansatz entwickelt werden mögen, anstatt mit dem Spezifikationsdokument zu beginnen. Zudem soll es „mehrere kompatible Implementierungen“ anstelle einer einzigen Referenzimplementierung geben.

Im Zuge der Übergabe an die Eclipse Foundation mussten zudem die einzelnen Java-EE-Technologien umbenannt werden. Daher heißt es nun beispielsweise nicht mehr „Java Servlet“, sondern fortan „Jakarta Servlet“ usw. Während diese Umbenennungen hier und da vielleicht als ärgerlich empfunden werden, haben sie durchaus auch etwas Gutes. Denn bei dieser Gelegenheit wurden die Namen der Technologien vereinheitlicht und teils auch vereinfacht. Bisher waren die Namen doch recht inkonsistent. So hieß es etwa „Java Architecuture for XML Binding“, aber „Java API for JSON Binding“. Die neuen Namen lauten in diesem Fall nun „Jakarta XML Binding“ und „Jakarta JSON Binding“. Der Wiedererkennungswert der neuen Namen ist insgesamt als sehr gut zu bewerten.

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

Kostenlos: Java-Dossier für Software-Architekten 2019

Auf über 30 Seiten vermitteln Experten praktisches Know-how zu den neuen Valuetypes in Java 12, dem Einsatz von Service Meshes in Microservices-Projekten, der erfolgreichen Einführung von DevOps-Praktiken im Unternehmen und der nachhaltigen JavaScript-Entwicklung mit Angular und dem WebComponents-Standard.

 

Wie geht’s weiter?

Nachdem nun also das erste Release von Jakarta EE verfügbar ist, kann es endlich losgehen mit der lange ersehnten Weiterentwicklung der Plattform. Viele Entwickler erhoffen sich neben einer allgemeinen Modernisierung vor allem neue Features, insbesondere für die Entwicklung von Microservices und für zeitgemäße Betriebsvarianten, wie Cloud oder Kubernetes.

Im Rahmen des MicroProfile-Projektes wurden bereits eine ganz Reihe interessanter Vorschläge entwickelt, die überwiegend auch schon eine gute Stabiltät aufweisen. Das MicroProfile liegt immerhin bereits in Version 3.0 vor, und diverse Implementierungen stehen Entwicklern zum Download bereit. Zu diesen Neuerungen zählen der Support für Metriken, Heath Checks und OpenTracing, die Unterstützung von OpenAPI, sowie Erweiterungen zur Verbesserung der Widerstandsfähigkeit von Anwendungen (Timeout, Retry, Fallback, Circuit Breaker, Bulkhead). Eine weitere sinnvolle Neuerung ist die Implementierung eines Config APIs, das es erlaubt, Konfigurationsparameter aus unterschiedlichen Quellen direkt in den Anwendungscode injizieren zu lassen. Bei den Konfigurationsquellen kann es sich um eine Datei, Umgebungsvariablen, System-Propertys oder um proprietäre Quellen wie eine Datenbanktabelle handeln. Die Unterstützung solcher proprietärer Quellen gelingt sehr leicht durch Implementierung eines Service Provider Interface (SPI). Die MicroProfile-Implementierung kümmert sich zum Zeitpunkt der Injizierung eines Konfigurationsparameters selbständig darum, alle vorliegenden Quellen nach einem passenden Konfigurationswert zu durchforsten.

Es wäre also naheliegend und wünschenswert, die im MicroProfile vorliegenden Neuerungen nun schrittweise nach Jakarta EE zu migrieren. Da die Entwicklung des MicroProfile bereits recht fortgeschritten ist, sollte dies aus technischer Sicht auch zeitnah zu bewerkstelligen sein. Und weitere interessante Neuerungen finden sich bereits auf der Roadmap des MicroProfile. Dort finden sich u.a. die Unterstützung von Reactive Streams, GraphQL, Event Data oder von reaktivem Zugriff auf relationale Datenbanken. Abseits des MicroProfile wurden aber auch in einigen der bestehenden Technologien, wie beispielsweise JAX-RS, einige neue Features vorangetrieben, die ebenfalls bald in die Plattform einfließen könnten. In diesem Zusammenhang sollte auch nicht unerwähnt bleiben, dass Jakarta EE einen deutlich kürzeren Release-Zyklus haben soll. Ganz ähnlich wie in Java SE geschehen, soll es häufigere Releases geben, die dafür jeweils nur kleinere Änderungen mitbringen. Somit ist zu hoffen, dass schon in naher Zukunft ein Jakarta EE Release mit neuen Features erscheinen wird.

Neben neuen Features sollen aber auch die Anwendungsentwicklung im Allgemeinen und der Einstieg in die Plattform vereinfacht werden. Erneut gibt das MicroProfile hier einen möglichen Weg vor. So wurde bereits eine „MicroProfile-Starter“-Webseite zur Verfügung gestellt – ganz ähnlich wie jene von Spring Boot. Auch generell ist zu beobachten, dass viele Konzepte des MicroProfile von anderen Frameworks abgekupfert erscheint. Dies ist jedoch nicht unbedingt negativ: Warum sollten Ideen, die sich andernorts bewährt haben, nicht übernommen werden? Im Gegenteil erleichtert doch der Wiedererkennungswert ein schnelleres Zurechtfinden in neuer (alter) Umgebung.

Schließlich ist auch eine Abkehr vom ursprünglichen Deployment-Modell schon längst erkennbar. Die Zeiten, in denen monolithische Application Server auf einem leistungsfähigen Server installiert und dort hinein mehrere Java-Enterprise-Anwendungen deployt wurden, gehören definitiv der Vergangenheit an. Sie passen nicht mehr zu aktuellen Trends wie Cloud oder Docker. So hat sich über die Jahre gezeigt, dass vielerorts in aller Regel nur noch eine einzige Anwendung in einen Application Server deployt wird, was im Umkehrschluss die Frage aufwirft, weshalb dieser Application Server dann eigentlich sämtliche Java-EE-Technologien unterstützen muss. Es wäre hingegen ausreichend, würden nur jene Technologien unterstützt, die von dieser einzigen deployten Anwendung tatsächlich benötigt werden. Mit Blick auf diese Entwicklung im Betrieb haben die Hersteller der Application Server ihre Produkte längst so weit modularisiert, dass für jede Anwendung eine passgenaue Variante eines Application Servers gebaut oder konfiguriert werden kann. Das Stichwort heißt hier „Just Enough App Server“. Zudem sind Build-Plug-ins etwa für Maven erhältlich, welche die notwendigen Application-Server-Module gemeinsam mit der Anwendung in eine einzige ausführbare JAR-Datei packen. Ein Modell, das sich deutlich besser mit Docker und Cloud verträgt – und ebenfalls von anderen Frameworks bereits vorgemacht wurde.

Bei aller Modernisierung und Weiterentwicklung soll einer der zentralen Pluspunkte der Vergangenheit auch künftig gewahrt bleiben: Es ist vorgesehen, die Rückwärtskompatibilität so weit wie irgend möglich zu erhalten, sodass auch ältere Anwendungen auf aktuellen Implementierungen von Jakarta EE lauffähig bleiben. Allerdings ist vorgesehen, ähnlich wie im Falle von Java SE, einige der ältesten Zöpfe abzuschneiden und vereinzelte Technologien mittelfristig aus der Plattform zu entfernen, oder zumindest als optional zu kennzeichnen. Dies soll vor allem APIs betreffen, die schon immer recht exotisch waren und nur vergleichsweise selten eingesetzt werden.

One last thing…

Es gibt also einiges zu tun. Doch leider steht der Weiterentwicklung von Jakarta EE noch ein letztes Hindernis im Weg: Eine Erweiterung der Plattform würde zwangsläufig eine Erweiterung der bestehenden APIs nach sich ziehen. Oracle hat jedoch die Verwendung der existierenden javax.enterprise.*-Packages nur in unverändertem Zustand genehmigt. Im Falle einer Änderung oder Erweiterung darf der Markenname „java“ nicht mehr verwendet werden. Dies verhindert faktisch eine Weiterentwicklung von Jakarta EE unter Beibehaltung der aktuellen Package-Struktur.

Einen neuen Package-Name zu finden war noch recht einfach (z.B. jakarta.*, also etwa jakarta.servlet). Wie genau jedoch die Umstellung erfolgen soll, wird noch diskutiert. Denn wenn die zugrundeliegenden Java APIs in neue Packages verschoben werden, dann werden zwangsläufig sämtliche bestehenden Anwendungen inkompatibel. Was also tun?

Zunächst ist zu klären, ob der Umstieg für alle Jakarta EE APIs in einem einzigen harten Schnitt passiert, oder ob die neuen Package-Namen schrittweise eingeführt werden. So könnten in jedem Release immer nur die tatsächlich geänderten APIs in neue Packages umziehen. Bislang ist noch nichts entschieden. Aber sollten sich die Verfechter eines harten Schnittes durchsetzen, dann würde das nächste Release „Jakarta EE 9“ vermutlich als einzige Neuerung diesen Umstieg auf die neuen Packages beinhalten, während neue Features erst ab „Jakarta EE 10“ zu erwarten wären. Glücklicherweise sind aber, wie bereits erwähnt, deutlich kürzere Release-Zyklen geplant als von Java EE gewohnt.

Eine damit verbundene Fragestellung lautet, wie man Unternehmen und Entwickler bestmöglich bei der Umstellung existierender Java-EE-Anwendungen unterstützen kann. Zum einen bestünde die Möglichkeit, Werkzeuge oder IDE Features anzubieten, die sämtliche Package-Abhängigkeiten einer bestehenden Anwendungsprojektes automatisch auf die neuen Packages umschreibt. Dies wäre auf Code-Ebene noch vergleichsweise leicht durchführbar, könnte aber bei Abhängigkeiten zu externen Bibliotheken zu größeren Schwierigkeiten führen. Ein anderer bereits geäußerter Vorschlag besteht darin, dass die Container wie Thorntail, Glassfish oder OpenLiberty diese Abbildung von alten auf neue Packages zur Laufzeit intern vornehmen, also vollkommen transparent für Anwendungsentwickler.

Fazit

Mit dem Erscheinen von Jakarta EE 8 ist ein sehr wichtiger Meilenstein für die Plattform erreicht. Es bleibt noch das Problem der Package-Namen zu lösen, dann kann es mit der Modernisierung und der Hinzunahme neuer Features endlich losgehen. Für Unternehmen, die zahlreiche auf Java EE basierende Anwendungen im produktiven Betrieb haben, sind dies gute Nachrichten. Aber auch für die Entwicklung neuer Anwendungen wird künftig möglicherweise Spring Boot nicht mehr der unangefochtene Platzhirsch sein. Im Dunstkreis des MicroProfile befinden sich gleich eine ganze Reihe spannender neuer Frameworks im Anmarsch, wie etwa Quarkus oder Micronaut. Es dürfte ein spannender Wettbewerb werden.

Geschrieben von
Thilo Frotscher
Thilo Frotscher
Thilo Frotscher arbeitet als freiberuflicher Softwarearchitekt und Trainer. Seine technischen Schwerpunkte sind die Java-Plattform sowie der Themenbereich Services und Systemintegration. Er unterstützt Unternehmen durch die Mitarbeit in Entwicklungsprojekten und die Durchführung praxisnaher Schulungen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: