Unsere Interview-Serie zu Jakarta EE: Thorben Janssen, freiberuflicher Consultant und Trainer

Jakarta EE im Klartext: „Wenn ich an Java EE 7 und 8 zurückdenke, würde ich mir für Jakarta EE kürzere Release-Zyklen wünschen“

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 Thorben Janssen, freiberuflicher Consultant und Trainer. 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 Thorben Janssen, freiberuflicher Consultant und Trainer. Ab geht die Reise ins Jakarta-EE-Universum!

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

Durch die Verschmelzung von Jakarta EE und MicroProfile würde man zwangsläufig Opfer bringen.

Thorben Janssen: Im Moment halte ich das für keine gute Idee, das mag sich in Zukunft aber vielleicht ändern. Einer der Hauptvorteile von Eclipse MicroProfile ist, dass es keinem strikten Standardisierungsprozess folgen muss, den man von Jakarta EE kennt. Dadurch können die jeweiligen Teams sehr viel schneller und innovativer arbeiten. Jakarta EEs Standardisierungsprozess hingegen steht für Stabilität, was für die langfristige Geschäftsplanung wichtig und vorteilhaft ist.

Verschmelzt man die Projekte nun, muss man zwangsläufig einen dieser Vorteile opfern. Daher glaube ich, dass es besser wäre, MicroProfile und Jakarta EE einzeln aber in enger Verbindung miteinander weiter voranzutreiben. Erfolgreiche MicroProfile-Spezifikationen können dann als Teil von Jakarta EE standardisiert werden.

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?

Thorben Janssen: Aus technischer Sicht decken MicroProfile und ein paar andere Open-Source-Projekte die damit verbundenen Herausforderungen bereits ab. Mit Jakarta EE könnte man sich also darauf konzentrieren, die bereits bestehenden Konzepte zu standardisieren und zu verbessern. Ein guter erster Schritt wäre etwa die Standardisierung von MicroProfile-Spezifikationen wie FaultTolerance oder Configuration. Für Jakarta EE muss außerdem der Spezifizierungsprozess beschleunigt werden, damit es mit den rasanten Cloud-Umgebungen Schritt halten kann.

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

Thorben Janssen: Die automatisches, horizontale Skalierung und die Containerisierung haben den Fokus im Jakarta-EE-Umfeld auf Fehlertoleranz, Konfiguration, Sicherheit, Metriken und Health Checks gelenkt. Früher wurden diese Dinge von Jakarta EE noch nicht wirklich adressiert, Cloud-native Anwendungen setzen dies allerdings voraus.

Eclipse MicroProfile stellt bereits eine solche Spezifikation zur Verfügung. Damit Jakarta EE vorankommt, wäre es das Einfachste, man würde sich diese Spezifikationen und das Feedback der Nutzer genauer anschauen. Die Specs könnten dann für Jakarta EE fit gemacht und darin integriert werden.

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?

Thorben Janssen: Auch hierfür gibt es bereits mehrere Spezifikationen von Eclipse MicroProfile, die den Herausforderungen von Microservices gewidmet sind. Die erfolgreichsten könnten einfach in Jakarta EE einfließen.

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?

Die Integration von Kubernetes sollte eine Priorität für Jakarta EE sein.

Thorben Janssen: Die Integration von Kubernetes sollte eine Priorität für Jakarta EE sein. Ich würde allerdings ein abstraktes API anstelle eines nativen Kubernetes APIs empfehlen. Dadurch würde die Spezifikation flexibler und man würde sich die starke Abhängigkeit von Kubernetes sparen. Die grundlegenden Services von Kubernetes würden so dennoch nutzbar und eine bessere Integration der Plattform wäre gegeben.

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?

Thorben Janssen: Wenn ich an Java EE 7 und 8 zurückdenke, würde ich mir für Jakarta EE durchaus kürzere Release-Zyklen wünschen. Die neue Release-Kadenz von Java hingegen wäre mir ein wenig zu schnell. Entwickler brauchen gut getestete und weitreichend unterstützte Releases, die nicht veraltet sind, bevor man die Software ausgeliefert hat.

Ein guter Zeitrahmen wäre vllt. eine neue Hauptversion alle 1 bis 2 Jahre. Die einzelnen Sub-Spezifikationen sollten allerdings in ihrem Zyklus unabhängig von der Dachspezifikation sein.

Die vorgeschlagenene Release-Kadenz würde es Eclipse MicroProfile und verschiedenen Jakarta-EE-Anbietern Zeit verschaffen, um neue Features zu implementieren und Feedback aus der Community zu sammeln. Darauf basierend können dann die erfolgreichsten und aufregendsten Features als Teil von Jakarta EE standardisiert werden.

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

Als Consultant und Trainer liegt mein Fokus stark auf Themen aus dem Bereich Persistenz, bei Jakarta EE und MicroProfile ist das nicht anders.

Thorben Janssen: Als Consultant und Trainer liegt mein Fokus stark auf Themen aus dem Bereich Persistenz, bei Jakarta EE und MicroProfile ist das nicht anders. Ich möchte mich daher in naher Zukunft mit der JPA-Spezifikation von Jakarta EE beschäftigen. Es gibt außerdem bislang keine Jakarta-EE-Spezifikationen für reaktiven Datenbankzugriff oder die Verwaltung von Events in CQRS-Architekturen. Sobald sich dies ändert, würde ich gerne an den entsprechenden Spezifikationen ebenfalls mitarbeiten.

Reaktive Streams und CQRS werden im Eclipse-MicroProfile-Projekt bereits heiß diskutiert. Diesen Diskussionen folge ich aufmerksam und ich hoffe, dass meine professionellen Beiträge mir bald erlauben, richtig mitzumischen.

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

Thorben Janssen: Die Community sollte geduldig sein, bis der Transfer der Spezifikationen zur Eclipse Foundation abgeschlossen ist. Sobald dies der Fall ist, können wir als Community die Zukunft von Jakarta EE bestimmen. Jeder, der sich für Jakarta EE interessiert oder mit der früheren Situation unzufrieden war, sollte an dem Prozess teilnehmen, Feedback geben, sich an den Diskussionen zu neuen Features beteiligen und Pull Requests einreichen. Damit kann jeder die Zukunft von Jakarta EE mitgestalten.

JAXenter: Vielen Dank für das Interview!

2wQFtkf9Thorben Janssen arbeitet als Seniorentwickler und Architekt für die Qualitype GmbH und entwickelt seit mehr als zehn Jahren Anwendungen auf Basis von Java EE. Er ist Mitglied der JSR 365 Expert Group und bloggt über Themen rund um Java Enterprise auf http://www.thoughts-on-java.org. Twitter: @thjanssen123
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

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: