Unsere Interview-Serie zu Jakarta EE: Christian Kaltepoth

Jakarta EE im Klartext: „Das User-Feedback ist von zentraler Bedeutung, damit Jakarta EE die richtige Richtung einschlagen kann“

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 Christian Kaltepoth, Senior Developer bei ingenit GmbH & Co. KG in Dortmund. 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 Senior Developer Christian Kaltepoth. Ab geht die Reise ins Jakarta-EE-Universum!

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

Das Thema Cloud ist für Jakarta EE sicherlich äußerst wichtig. Im Vergleich zu anderen Technologien und Frameworks gibt es hier einiges nachzuholen.

Christian Kaltepoth: Um diese Frage zu beantworten, muss man die Entstehungsgeschichte der MicroProfile-Initiative genauer betrachten. Gegründet wurde MicroProfile zu einer Zeit, in der es keinerlei Fortschritt bei Java EE gab. Daher kann MicroProfile in gewisser Weise als Reaktion auf die Passivität von Oracle und die Schwerfälligkeit des JCP zurückgeführt werden.
Inzwischen hat sich die Situation natürlich deutlich geändert. Aus Java EE ist Jakarta EE geworden und wird nun von der Eclipse Foundation weiterentwickelt. Auch wenn noch nicht in allen Details Klarheit darüber besteht, wie die Arbeit an Jakarta EE in Zukunft konkret weitergehen wird, so lässt sich doch bereits erahnen, dass es ein deutlich offenerer und flexiblerer Prozess wird, als wir es aus der Vergangenheit von Java EE kennen.

In gewisser Weise sind einige Ansätze bei Jakarta EE und MicroProfile sehr ähnlich, wie beispielsweise die konsequente Anwendung des „Code First“-Prinzips. Trotzdem glaube ich nicht, dass die beiden unmittelbar zusammengeführt werden sollten. Ich sehe MicroProfile eher als Innovationstreiber, der mit einem sehr leichtgewichtigen Prozess schnelle Ergebnisse liefern kann, die dann später wiederum eventuell in Jakarta EE einfließen können. Dass so etwas in der Praxis funktionierten kann, sieht man sehr schön am Configuration JSR, welcher ja auch zu einem gewissen Anteil durch MicroProfile Config inspiriert wurde.

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?

Christian Kaltepoth: Das Thema Cloud ist für Jakarta EE sicherlich äußerst wichtig. Im Vergleich zu anderen Technologien und Frameworks gibt es hier einiges nachzuholen. Dazu muss man verstehen, dass Java EE aus einer Zeit stammt, in der Unternehmen teure Lizenzen für kommerzielle Anwendungsserver gekauft haben, um auf einzelnen Instanzen dieser Server möglichst viele Anwendungen zu betreiben. Dieses Modell ist heute sicherlich nicht mehr so beliebt wie früher. Die Cloud eröffnet diesbezüglich natürlich ganz neue Möglichkeiten, aber auch neue Herausforderungen.

In gewisser Weise denke ich, dass MicroProfile schon sehr wichtige Schritte in Richtung Cloud gegangen ist. Die Unterstützung von Cloud- und Microservices-Architekturen stand ja schon immer im Fokus von MicroProfile. Denkt man beispielsweise an MicroProfile Fault Tolerance, Rest Client und andere Spezifikationen, so könnte ich mir gut vorstellen, dass diese auch für Jakarta EE geeignet sind. MicroProfile hat hier auf jeden Fall sehr wertvolle Vorarbeit geleistet.

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?

Christian Kaltepoth: Ich denke in diesem Punkt könnte Jakarta EE noch mehr in Richtung „Leichtgewichtigkeit“ tun. Wie man von Frameworks wie Spring Boot oder Dropwizard ja weiß, sind leichtgewichtige Server besonders in der Welt der Microservices sehr wichtig. Für Java EE ist das natürlich auch kein neues Thema. Wildfly Swarm (heute Thorntail), Payara Micro und ähnliche Projekte haben bereits gezeigt, dass sich auch Java-EE-Server als leichtgewichtige Runtimes eignen und selbst das Executable-JAR-Konzept für Java-EE-Anwendungen funktioniert. In dieser Richtung könnte ich mir mehr Standardisierung vorstellen. Vielleicht in Form eines speziellen Profils, welches neben dem Web- und Full-Profile durch Applikationsserver angeboten werden kann.

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?

Ich denke, Jakarta EE könnte noch mehr in Richtung Leichtgewichtigkeit tun.

Christian Kaltepoth: Zugegebenermaßen scheint sich Kubernetes momentan zu einem De-Facto-Standard für die Orchestrierung von Docker-Containern zu entwickeln. Daher wundert mich nicht, dass in einer solchen Umfrage verbesserte Integration gewünscht wird. Allerdings muss man auch beachten, dass sich Java-EE-Anwendungen auch heute schon problemlos in Docker-Containern betreiben lassen. Und selbstverständlich können diese Docker-Container auch in Kubernetes-Umgebungen ausgeführt werden. Von daher sehe ich zum aktuellen Zeitpunkt auch keine wesentlichen Aspekte, die Jakarta EE in diesem Zusammenhang verbessern könnte oder sollte. Außerdem muss man natürlich auch beachten, dass Kubernetes zwar in aller Munde ist, aber es durchaus Alternativen gibt. Docker Swarm beispielsweise ist gerade aufgrund seiner Einfachheit ebenfalls sehr beliebt. Daher stellt sich auch die Frage, warum Jakarta EE ein spezielles System bevorzugen sollte.

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?

Christian Kaltepoth: Ich denke, dass man bezüglich des Releasezyklus‘ einen guten Mittelweg finden muss. Ein Jakarta EE Release alle 6 Monate zu veröffentlichen, wäre meiner Meinung nach nicht machbar. Diese Zeitspanne wäre für ein volles Release viel zu kurz. Besonders unter Betrachtung der Tatsache, dass in dieser Zeit nicht nur die Spezifikationen erarbeitet, sondern auch durch das PMC und das Specification Committee abgesegnet werden müssen. Auf der anderen Seite will natürlich niemand, dass es nur alle 2 bis 3 Jahre eine neue Version von Jakarta EE gibt. Das wäre mit dem ständigen Wandel, den man in der IT immer wieder beobachtet, einfach nicht flexibel genug. Daher würde ich hoffen, dass Jakarta EE einen gesunden Mittelweg zwischen diesen Extremen findet.

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

Christian Kaltepoth: Da ich seit vielen Jahren fast täglich mit Java EE zu tun habe, freut es mich natürlich sehr, dass zukünftig noch mehr Möglichkeiten bestehen, Einfluss auf die Weiterentwicklung der Plattform zu nehmen. Es gibt eine ganze Reihe von sehr interessanten Spezifikationen, bei denen ich mir vorstellen könnte, aktiv mitzuarbeiten.

JAX-RS ist gerade wahrscheinlich das aktivste EE4J-Projekt und es wird schon fleißig an der nächsten Version gearbeitet.

Besonders interessiert mich allerdings JAX-RS. Daher bin ich auch vor kurzem dem Eclipse Project for JAX-RS als Committer beigetreten. Erfreulicherweise ist JAX-RS gerade das wahrscheinlich aktivste EE4J-Projekt, bei dem schon sehr fleißig an der nächsten Version gearbeitet wird. Für mich persönlich ist dabei eine verbesserte Integration mit CDI das wichtigste Thema. Aus historischen Gründen kommt JAX-RS mit einem eigenen Komponentenmodell und einem eigenen Mechanismus für Dependency Injection daher. Da CDI allerdings zu Recht ein immer zentralerer Bestandteil der Plattform wird, sollte die Integration hier deutlich verbessert werden.

Darüber hinaus bin ich aber auch sehr an den TCKs interessiert. Diese waren in der Vergangenheit, zumindest im Falle der Oracle JSRs, nicht frei verfügbar und man hörte lediglich immer wieder, dass die TCKs sehr komplex und nur schwer zu erweitern sind. Für mich sind die TCKs aber auch deshalb interessant, weil ich gerade aktiv an dem quelloffenen TCK für JSR 371 (MVC 1.0) arbeite und durch die Arbeit an JAX-RS zukünftig auch mit dem alten Oracle TCK zu tun haben werde. Falls sich wirklich herausstellen sollte, dass sich das alte Oracle TCK nur schwer erweitern lässt, wäre es natürlich sehr spannend herauszufinden, ob sich dieses in irgendeiner Form modernisieren lässt, beispielsweise durch eine schrittweise Migration zu Arquillian.

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

Christian Kaltepoth: Die aktuelle Entwicklung ist der wahrscheinlich größte und wichtigste Evolutionsschritt in der Geschichte von Java EE. Lange Zeit hat fast ausschließlich Oracle über die Zukunft der Plattform entschieden. Dabei waren doch einige der Entscheidungen nicht unumstritten. Und besonders das Jahr 2016, in dem Oracle für fast ein Jahr die Arbeit an Java EE 8 fast komplett eingestellt und somit sämtlichen Fortschritt blockiert hat, zeigte besonders deutlich, dass mehr als nur ein „Big Player“ für die Weiterentwicklung der Plattform verantwortlich sein sollte.

Daher glaube ich fest daran, dass Jakarta EE bei der Eclipse Foundation in guten Händen ist. Die Eclipse Foundation hat seit vielen Jahren Erfahrung mit großen Open-Source-Projekten und es deutet sich bereits an, dass neben den großen Herstellern auch viele kleinere Parteien mit von der Partie sein werden und sich in Jakarta EE einbringen wollen. Und das kann auch jeder interessierte Entwickler machen. Die Mailing-Listen sind offen und jeder kann Feedback einbringen. Und gerade das halte ich für sehr wichtig. Besonders das Feedback der User ist von zentraler Bedeutung, damit Jakarta EE für die Zukunft die richtige Richtung einschlagen kann.

JAXenter: Worum geht es im Eclipse-Projekt Ozark?

MVC 1.0 war die erste Spezifikation, die von Oracle an die Community übergeben wurde und wird nun sehr offen weitergeführt.

Christian Kaltepoth: Ozark ist die Referenzimplementierung von JSR 371, der Model-View-Controller-Spezifikation, die ursprünglich eine leichtgewichtige Alternative zu JavaServer Faces für Java EE 8 werden sollte. Leider hatte Oracle im letzten Moment die Prioritäten verschoben, sodass es MVC 1.0 nicht mehr in Java EE 8 geschafft hat.

Glücklicherweise hatte es Oracle allerdings ermöglicht, dass die Community die Spezifikation weiter vorantreiben konnte, sodass MVC 1.0 nun endlich kurz vor dem Abschluss steht. In gewisser Weise könnte man sagen, dass MVC 1.0 die erste Spezifikation war, die von Oracle an die Community übergeben wurde und die nun sehr offen weitergeführt wird. Daher denken wir, dass MVC 1.0 (genau wie die anderen Bestandteile von Java EE) sehr gut bei der Eclipse Foundation aufgehoben sein wird und streben daher an, MVC als eigenes Unterprojekt von EE4J weiterentwickeln zu können. Ozark ist als Referenzimplementierung ein sehr zentraler Bestandteil der Spezifikation. Daher haben wir beschlossen, in einem ersten Schritt Ozark zur Eclipse Foundation zu transferieren.

JAXenter: Wie sieht die Zukunft von Eclipse Ozark aus?

Christian Kaltepoth: Zunächst planen wir den Transfer zur Eclipse Foundation komplett abzuschließen. Das ist leider nicht ganz so einfach, wie es klingt. Neue Eclipse-Projekte müssen eine ganze Reihe von Phasen durchlaufen, in deren Rahmen rechtliche Voraussetzungen geprüft werden. Da geht es dann beispielsweise um das geistige Eigentum am Quellcode, die Lizenz des Projektes und der Abhängigkeiten, um potentielle Konflikte zwischen dem Projektnamen und existierender Trademarks und vieles mehr. Dabei hat sich herausgestellt, dass der Name Ozark problematisch sein könnte und wir somit einen neuen Namen für die Referenzimplementierung benötigen. Diese Themen sind aktuell in Klärung. Wir hoffen allerdings, dass der Transfer bald abgeschlossen sein wird.

Der Name Ozark wird aller Vorraussicht nach ersetzt werden müssen.

Unabhängig davon wird natürlich auch sonst aktiv an dem Projekt gearbeitet. Neben der Umsetzung der letzten Änderungen, die sich noch an der Spezifikation ergeben haben, ist auch die Kompatibilität mit den verschiedenen Java-EE-Servern noch ein Thema. Aktuell funktioniert Ozark sehr gut mit GlassFish, WildFly und Payara. An der Unterstützung von Apache TomEE und WebSphere Liberty wird zurzeit noch gearbeitet.

JAXenter: Vielen Dank für das Interview!

Christian KaltepothChristian 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 Specification Lead der JSR 371 Expert Group, JAX-RS Committer und ein regelmäßiger Sprecher auf Konferenzen.
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: