Unsere Interview-Serie zu Jakarta EE: Guillermo González de Agüero, Eclipse Soteria & Eclipse Project für Enterprise Security Committer

Jakarta EE im Klartext: „Jakarta EE ist nur noch ein Schirm, unter dem alle einzelnen Projekte vereint sind“

Dominik Mohilo, Gabriela Motroc

© Shutterstock / LuckyN (modifiziert)

Na, auch ein wenig den Anschluss in Sachen Jakarta EE verloren? Das macht nichts. In unserer Interview-Reihe sprechen Experten der Enterprise-Java-Szene Klartext darüber, was sich im Laufe der letzten Wochen und Monate verändert hat und in welche Richtung sich Jakarta EE entwickelt. Zentrales Thema ist dabei unter anderem, wie Jakarta EE zum neuen Zuhause für Cloud-native Java werden soll. Unser heutiger Gast ist Guillermo González de Agüero, Eclipse Soteria & Eclipse Project für Enterprise Security Committer. Ab geht die Reise ins Jakarta-EE-Universum!

Es ist wahrlich kein leichtes Unterfangen, dieser Umzug der Java-EE-Technologie von Oracle zur Eclipse Foundation. Die Marke „Jakarta EE“ entwickelt sich prächtig und schnell. Zeit, für einen Moment innezuhalten und all die Pläne und Veränderungen Revue passieren zu lassen, um die Technologie fit für die neuen Herausforderungen in Sachen Cloud, Containern, Microservices, Serverless und reaktiver Programmierung zu machen.

Die Vision der technischen Zukunft von Jakarta EE beinhaltet Folgendes:

  • Eine verbesserte Unterstützung von Microservices-Architekturen.
  • Der Weg hin zu Cloud-native Java, was unter anderem die bessere Integration mit Technologien wie Docker und Kubernetes bedeutet.
  • Das Beschleunigen der Innovationsgeschwindigkeit.
  • Den Aufbau einer aktiven und engagierten Entwickler-Community.
  • Das Bereitstellen von produktionsreifen Referenzimplementierungen.

Immer auf dem Laufenden zu bleiben, was in Sachen Jakarta EE gerade in und was gerade out ist, bleibt ein kontinuierlicher Prozess. Mit Sicherheit können allerdings die bereits akzeptierten und in der Eclipse Foundation offiziell verorteten Projekte identifiziert werden. Unsere Liste von bereits angenommenen Projektvorschlägen hilft dabei, sich einen Überblick über den Status Quo zu verschaffen, aber das ist natürlich nur die Spitze des Eisbergs.

Welchen Herausforderungen sieht sich Jakarta EE derzeit gegenüber? Welche werden wohl in naher Zukunft aufkommen? Wohin geht die Reise überhaupt und wie wird die Zukunft von Enterprise Java aussehen? Mit unserer Interview-Serie wollen wir euch helfen, die aktuellen Entwicklungen im Blick zu behalten. Unsere Experten beleuchten die Hintergründe und klären darüber auf, wie es um die Zukunft der Technologie bestellt ist und wie man plant, Jakarta EE als neues Zuhause für Cloud-native Java zu etablieren.

Unsere Interview-Reihe: Jakarta EE im Klartext

In unserer Interview-Reihe sprechen Experten der Enterprise-Java-Szene Klartext darüber, was sich im Laufe der letzten Wochen und Monate verändert hat und in welche Richtung sich Jakarta EE entwickelt. Zentrales Thema ist dabei unter anderem, wie Jakarta EE zum neuen Zuhause für Cloud-native Java werden soll.

Ab geht die Reise ins Jakarta-EE-Universum mit unseren Experten!

Unser heutiger Experte ist Guillermo González de Agüero, Eclipse Soteria & Eclipse Project für Enterprise Security Committer. Ab geht die Reise ins Jakarta-EE-Universum!

JAXenter: Hallo, Guillermo! Glaubst du, es wäre eine gute Idee, Eclipse MicroProfile mit Jakarta EE zu verschmelzen?

Jakarta EE bietet ein solides und stabiles Fundament, während MicroProfile Innovationen und eher experimentelle Funktionen bietet.

Guillermo González de Agüero: MicroProfile und Jakarta EE ergänzen sich gegenseitig. Jakarta EE bietet ein solides und stabiles Fundament, während MicroProfile Innovationen und eher experimentelle Funktionen bietet. Sie müssen definitiv in irgendeiner Weise ineinander integriert werden, aber sie spielen unterschiedliche Rollen und müssen sich, meiner Meinung nach, als solche ihre Unabhängigkeit bewahren. Ich würde es begrüßen, wenn die bewährten MicroProfile-Spezifikationen in Jakarta EE oder den JCP implementiert würden.

Der erste Schritt in Richtung Integration wäre, MicroProfile im Rahmen des EE4J-Projekts unter das Dach der Eclipse Foundation zu verschieben, sodass sich MicroProfile das PMC mit Jakarta EE teilt. Danach müssen die beiden Projekte entscheiden, wie sie die soliden Spezifikationen von MicroProfile in Jakarta EE implementieren. Die MicroProfile Community wird entscheiden müssen, ob sie die Entwicklung von Spezifikationen, die bereits in das JCP oder Jakarta EE verschoben wurden, separiert fortsetzen will.

JAXenter: Der Pfad, den man mit Jakarta EE beschreiten möchte, wurde bereits klar definiert und nennt sich Cloud-native Java. Wie erreicht man dieses Ziel?

Guillermo González de Agüero: Ich weiß nicht, was andere Leute denken, aber meiner Meinung nach hat MicroProfile Java EE gerettet und wird eine Schlüsselrolle bei seiner Transformation hin zu Cloud-native spielen. MicroProfile unterstützt wesentliche Cloud-Funktionen, wie Health Checks, Request Tracing sowie Fehlertoleranz und man arbeitet innerhalb des Projektes bereits an sogenannten LRA-Spezifikationen für das Ersetzen von Transaktionen und reaktivem Messaging.

Java EE hatte keinen Ort zum Experimentieren und konzentrierte sich lediglich auf die Standardisierung wirklich bewährter Lösungen, aber die Industrie verlangt nun, dass die Dinge sich schneller entwickeln. MicroProfile könnte der Ort sein, an dem die „Early Adopters“ neue Funktionen testen können.

JAXenter: Wie kann Jakarta EE die Cloud-bezogenen Bedürfnisse der Nutzer befriedigen?

Guillermo González de Agüero: Ein Feature, das ich gerne sehen würde und das bereits auf der Mailing-Liste von Jakarta EE diskutiert wurde, ist die Unterstützung zusammensetzbarer Laufzeiten, bei denen Benutzer auf einfache Art die Komponenten einfach auswählen können, die sie verwenden möchten. Sie bekommen so einen benutzerdefinierten Anwendungsserver, auf dem nur das und nichts anderes enthalten ist. Einige Container bieten bereits eine proprietäre Möglichkeit dafür an und ich denke, dass wir genug Erfahrung haben, um dahingehend nach einem Standard zu suchen. Hoffentlich können wir das Projekt gleichzeitig an das Java Modulsystem anpassen, das mit Java 9 veröffentlicht wurde.

Einige Leute denken, dass die Unterstützung der Java SE durch Jakarta-EE-Komponenten der Schlüssel für den weiteren Erfolg sein wird.

Die Nutzung eines Modulsystems bedeutet, dass wir auch von Jlink- und benutzerdefinierten Java-Laufzeiten profitieren können. Ich bin mir nicht sicher, welchen Leistungs-/Größenvorteil wir dadurch haben werden, aber es ist definitiv etwas, das es zu erforschen gilt.

Einige Leute denken, dass die Unterstützung der Java SE durch Jakarta-EE-Komponenten der Schlüssel für den weiteren Erfolg sein wird. JAX-RS zum Beispiel arbeitet aus diesem Grund an einem eigenständigen API, genau wie man es bei CDI für Version 2.0 getan hat. Das wird auch bei Serverless-Architekturen helfen, die wir ebenfalls im Auge behalten müssen.

JAXenter: Konzentrieren wir uns auf die Ergebnisse des Jakarta EE Surveys. Über 60 Prozent der Teilnehmer würden eine bessere Unterstützung von Microservices begrüßen. Wie würdest du dem nachkommen?

Guillermo González de Agüero: Jakarta-EE-Spezifikationen sind bereits ziemlich stabil und zuverlässig. Es ist großartig zu hören, dass Nutzer nach einer besseren Unterstützung von Microservices fragen, denn das heißt ja, dass Jakarta EE immer noch als wertvoll für moderne Architekturen angesehen wird! Aber Microservices sind ein sehr breites Thema und deshalb müssen wir insgesamt verstehen, was die User wirklich wollen.

Meiner Meinung nach brauchen wir einfachere Wege, um zwischen Microservices zu kommunizieren. Ferngesteuerte CDI-Events wären ein großer Schritt nach vorne und könnten verschiedene Nachrichten von verschiedenen Backends unterstützen, sie wären zudem nicht auf Java beschränkt. Clustering-, Fail-Over- und Load-Balancing-Funktionen sind ebenfalls selbstverständlich, aber sie sind meist proprietär und daher nicht portierbar.

JAXenter: Die native Integration von Kubernetes ist ein weiterer wichtiger Faktor, wie die Umfrage gezeigt hat. Sollte dies für Jakarta EE eine Priorität darstellen?

Wir können viel tun, um Container im Allgemeinen besser zu unterstützen, bevor wir uns auf spezifische Orchestratoren verlassen.

Guillermo González de Agüero: Dieses Ziel ist sehr eng mit dem vorhergehenden Punkt verknüpft. Health Checks in Bezug auf die „Liveness“ bzw. „Readiness“ sind das erste, was mir in den Sinn kommt. Aber wir können viel tun, um Container im Allgemeinen besser zu unterstützen, bevor wir uns auf spezifische Orchestratoren verlassen.

Einige Anbieter bieten bereits viele proprietäre Funktionen an, die sehr hilfreich sind. Aber bei Jakarta EE geht es um Standards, also müssen wir uns ansehen, welche dieser Funktionen sich zum Standard eignen. Möglicherweise müssen wir das Deployment-Modell für Jakarta-EE-Anwendungen noch einmal überarbeiten und anstelle von traditionellen Anwendungsservern eher Hollow Uberjars standardisieren und promoten. Das Config API ist ein Muss für verschiedene Phasen einer Anwendung, aber ich würde auch gerne Funktionen für portables Clustering, Server-Discovery und Session-Replikation nutzen können.

JAXenter: Würdest du eine höhere Release-Kadenz (wie es nun bei Java der Fall ist) oder lieber größere und langsamere Releases bevorzugen?

Guillermo González de Agüero: Schnellere Releases sind dringend erforderlich. Wir können ein Release nicht um Jahre hinauszögern, wenn einige Verbesserungen und Neuerungen bereits abgeschlossen sind, nur um auf den Abschluss von weiteren Arbeiten zu warten.

Einer der wichtigsten Aspekte der jüngsten Entwicklungen ist, dass wir jetzt in der Lage sind, neue Versionen einzelner Komponenten unabhängig vom Release-Zyklus der Plattform zu entwickeln und zu veröffentlichen. Solange der JCP das Maß der Dinge war, konnte Java EE nicht weiterentwickelt werden, wenn keine neue Version anstand. Und selbst dann gab es nur wenige Spezifikationen, an denen aktiv gearbeitet wurde und die eine funktionierende Expert Group hatten. Um ein Beispiel zu geben: Während der Arbeit an Java EE 8 hätte die Expert Group der Java Server Faces (JSF) gerne einige Änderungen an der Expression-Language-Spezifikation durchgeführt, aber die EL-Spezifikation wurde nicht aktiv betreut, sodass dies schlicht nicht umsetzbar war.

Unter dem Dach der Eclipse Foundation sind nun alle Projekte völlig unabhängig und haben einen eigenen Lebenszyklus. Jakarta EE ist nur noch ein Schirm, unter dem sie alle vereint sind. Dies wird den Übergang zu eigenständigen Komponenten erleichtern, und ich denke, dass dadurch die Mitarbeit an den einzelnen Projekten steigt.

Was das Plattformprojekt betrifft, befürworte ich persönlich einen jährlichen Release-Zyklus. Allerdings müssen die Anbieter herausfinden, wie sie den Kunden-Support managen. Die meisten Anbieter, die ich kenne, bieten derzeit bis zu 10-jährige Support-Verträge für ihre Hauptversionen an, was nicht mehr tragbar wäre, wenn es jedes Jahr eine Hauptversion gibt. Wahrscheinlich brauchen wir (wie Java SE) eine Art LTS-Version, wenn wir diesen Weg einschlagen wollen.

JAXenter: Wie planst du dich in den Entwicklungsprozess von Jakarta EE einzubringen? Gibt es irgendwelche Spezifikationen oder TCKs, die dich besonders interessieren?

Jakarta EE ist nur noch ein Schirm, unter dem alle einzelnen Projekte vereint sind.

Guillermo González de Agüero: Ich war Contributor für die Spezifikation JSR 375 (Security API) und bin nun Committer für die entsprechenden Eclipse-Projekte. Meine Beteiligung begann, nachdem ich selbst mit einigen Einschränkungen konfrontiert war, aber es gibt noch viel Raum für große Verbesserungen mit wenig Aufwand. Die Weiterentwicklung des Eclipse-Soteria-Projekts hat bereits begonnen und wir planen derzeit die Veröffentlichtung von Version 1.1 mit einigen Bugfixes, sowie verbesserter Portabilität, sobald es uns erlaubt ist.

Das TCK habe ich auch im Auge. Zunächst wird Oracle ein Repository übergeben, das die Testsuite für die gesamte Jakarta-EE-Plattform beinhaltet. Es besteht Einigkeit darüber, dass die Testsuite aufgeteilt werden muss, sodass jedes Projekt sein eigenes TCK enthält. Dadurch werden die Projekte unabhängiger voneinander und interessierte Parteien werden sich leichter damit tun, einzelne Implementierungen zu zertifizieren als komplette Jakarta-EE-Laufzeiten.

JAXenter: Wie sollte die Community mit den Veränderungen umgehen, die in letzter Zeit stattgefunden haben?

Guillermo González de Agüero: Es gibt noch einige offene Fragen. Zum Beispiel hat Oracle alle APIs gespendet, allerdings ist es aufgrund von rechtlichen (insb. urheberrechtlichen) Problemen eher unwahrscheinlich, dass dies auch mit allen Dokumenten der Spezifikationen machen werden. Ich bin ein wenig besorgt über die Auswirkungen, die dies haben könnte. Die Community kann nicht zwei weitere Jahre warten, bis die Spezifikationen wieder verfügbar sind.

Die Nutzer können sich darauf freuen, bald mit verbesserten und portableren Laufzeiten arbeiten zu können, wobei das Open Sourcing der TCKs eine wichtige Rolle spielt. Außerdem können bald sicher Alternativen für individuelle Komponenten genutzt werden.

Durch all diese Veränderungen fegt ein frischer Wind durch die Community. Alle sind dazu aufgefordert, die Neuigkeiten und die Entwicklungen in Sachen Jakarta EE zu verbreiten und sich auf den Mailing-Listen sowie in individuellen Projekten zu beteiligen.

JAXenter: Vielen Dank für das Interview!

Guillermo González de Agüero is an Eclipse Soteria & Eclipse Project for Enterprise Security Committer.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Jakarta EE im Klartext: „Jakarta EE ist nur noch ein Schirm, unter dem alle einzelnen Projekte vereint sind“"

avatar
400
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

„Ein Feature, das ich gerne sehen würde und das bereits auf der Mailing-Liste von Jakarta EE diskutiert wurde, ist die Unterstützung zusammensetzbarer Laufzeiten, bei denen Benutzer auf einfache Art die Komponenten einfach auswählen können, die sie verwenden möchten. “

„zusammensetzbare Laufzeiten“ finde ich sehr unglücklich übersetzt. 🙂 Im Original heisst es „composable runtimes“.

Grüße