Unsere Interview-Serie zu Jakarta EE: Thilo Frotscher

Jakarta EE im Klartext: „Die Plattform muss insgesamt den Betrieb in Cloud und Containern besser unterstützen“

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 Thilo Frotscher, freiberuflicher Softwarearchitekt, Trainer und Experte für Enterprise Java sowie Systemintegration. 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!

Thilo Frotscher, freiberuflicher Softwarearchitekt, Trainer und Experte für Enterprise Java sowie Systemintegration. Ab geht die Reise ins Jakarta-EE-Universum!

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

Thilo Frotscher: Es wäre auf jeden Fall wünschenswert, dass einige der in MicroProfile implementierten APIs künftig in Jakarta EE integriert werden. Denn aus meiner Sicht wurden hier zum ganz überwiegenden Teil sehr sinnvolle Erweiterungen geschaffen, die der Plattform bislang noch fehlen. Ob die beiden Eclipse-Projekte organisatorisch zusammengeführt oder weiterhin getrennt voneinander bleiben sollten, ist dagegen eine ganz andere Frage. Dies könnte auch Nachteile haben, beispielsweise dass MicroProfile dann an bestimmte Prozesse von Jakarta EE gebunden wäre, was den bislang rasanten Fortschritt wieder verlangsamen könnte.

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?

Die Plattform muss insgesamt den Betrieb in Cloud und Containern besser unterstützen.

Thilo Frotscher: Die Plattform muss insgesamt den Betrieb in Cloud und Containern besser unterstützen. Natürlich ist ein solcher Betrieb auch mit Java EE schon möglich. Aber andere Frameworks und Technologien haben hier einfach deutlich die Nase vorne, da gibt es einiges aufzuholen. Gleichzeitig muss aber natürlich bedacht werden, dass auch weiterhin nicht alle Anwendungen in der Cloud betrieben werden. Es sollte daher angestrebt werden, verschiedene alternative Szenarien für den Betrieb zu bestmöglich zu unterstützen.

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?

Thilo Frotscher: Genau dieses Thema wurde ja bereits durch MicroProfile aufgegriffen, und viele wichtige Features für den Support von Microservices wurden bereits geschaffen. Es wäre sinnvoll, diesen Weg weiter zu beschreiten, und innerhalb von MicroProfile auch die noch fehlenden Puzzleteile zu entwickeln.

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?

Thilo Frotscher: Aus meiner Sicht eher nicht. Kubernetes mag momentan eine von vielen Entwicklerteams bevorzugte Plattform sein, aber wer weiß schon, welche Lösung in einigen Jahren die Nase vorne hat? Ich würde daher eher dafür plädieren, eine eher generische Lösung anzustreben, für welche dann die Integration mit Kubernetes nur eine von potentiell mehreren möglichen Implementierungen darstellt. Eine andere Implementierung könnte die Integration mit Docker Swarm sein. Die Java-EE-Plattform ist in der Vergangenheit sehr gut damit gefahren, generische Ansätze zu verfolgen und keine spezifischen Technologien zu bevorzugen.

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?

Es wäre auf jeden Fall wünschenswert, wenn es künftig deutlich kürzere Release-Zyklen gäbe.

Thilo Frotscher: Es wäre auf jeden Fall wünschenswert, wenn es künftig deutlich kürzere Release-Zyklen gäbe. In der Vergangenheit waren diese einfach zu lang. Gleichzeitig müssen Implementierungen neuer Jakarta EE Releases künftig deutlich schneller zur Verfügung stehen. Ich bin sehr zuversichtlich, dass dies auch erreicht werden kann. Zum einen deshalb, weil im Falle kürzerer Release-Zyklen jeweils auch weniger neue Features zu implementieren wären. Zum anderen soll künftig ohnehin eher ein Ansatz gelebt werden, bei dem zuerst implementiert und erst dann spezifiziert wird.

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

Thilo Frotscher: Ich habe noch nicht entschieden, wo und wie ich mich einbringen könnte. Grundsätzlich bin ich aber an allen Themen sehr interessiert, bei denen es um Kommunikation und Schnittstellen zwischen Systemen geht.

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

Es wird sehr wichtig sein, dass die Community die neuen Möglichkeiten der Beteiligung nutzt.

Thilo Frotscher: Es wird sehr wichtig sein, dass die Community die neuen Möglichkeiten der Beteiligung nutzt. Dies kann in unterschiedlicher Form erfolgen, etwa durch Mitarbeit an Specs und Implementierungen oder auch durch regelmäßiges Feedback, das Melden von Bugs und die Erstellung möglicher Patches. Insbesondere Unternehmen mit mittleren bis großen Entwicklerteams sind gefordert. Wenn diese Java im großen Umfang für ihre eigenen Anwendungen oder gar für ihre Produkte einsetzen, dann würde ich hoffen, dass diese künftig den ein oder anderen Entwickler für die Weiterentwicklung und Pflege von Jakarta EE abstellen. Dies muss ja nicht in Vollzeit geschehen. Aber wenn all jene Unternehmen nur 1-2% ihrer Entwicklungszeit zu dieses Zweck einsetzen würden, dann wäre doch schon viel geholfen.

Jakarta EE ist nun Open Source, und die Beteiligung an der Plattform wurde stark vereinfacht. Beides ist lange und verbreitet gefordert worden. Nun gilt es, auch Taten folgen zu lassen. Ich denke, dass man als Unternehmen auch an Attraktivität gegenüber potentiellen Kandidaten gewinnt, wenn man solche Aktivitäten anbieten kann. Zudem kann es durchaus von Nutzen sein, die Ausrichtung der Plattform und neue Features mitzubestimmen.

Thilo Frotscher arbeitet als freiberuflicher Softwarearchitekt und Trainer. Als Experte für Enterprise Java und Systemintegration unterstützt er seine Kunden überwiegend durch Entwicklung, Reviews oder die Durchführung von Schulungen. Thilo ist (Co-)Autor mehrerer Bücher in den Bereichen Java EE, (Web) Services und Systemintegration, hat zahlreiche Fachartikel verfasst und spricht regelmäßig auf Fachkonferenzen und Schulungsveranstaltungen oder bei Java User Groups.
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: