Unsere Interview-Serie zu Jakarta EE: Richard Monson-Haefel

Jakarta EE im Klartext: „Ein sehr schneller Release-Zyklus ist nichts, was die Community wollen oder gebrauchen 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 Richard Monson-Haefel, Co-Founder von OpenEJB, Java-EE-Autor & JCP EC Alumni. 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!

Richard Monson-Haefel, Co-Founder von OpenEJB, Java-EE-Autor & JCP EC Alumni. Ab geht die Reise ins Jakarta-EE-Universum!

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

Richard Monson-Haefel: Diese Frage wird oft gestellt. Viele glauben wohl, dass dies der Fall ist, ist es aber nicht. Das Projekt MicroProfile wurde nicht nur deswegen ins Leben gerufen, um ein auf Microservices fokusiertes Framework zu erschaffen, sondern weil Java EE unter dem JCP einen kompletten Stillstand erlebte. Das MicroProfile-Projekt entwickelt sich sehr schnell und das Resultat ist ein kontinuierlicher Fortschritt.

Das Jakarta-Projekt steckt hingegen noch in den Kinderschuhen und es wird noch eine Weile dauern, bis alles so reibungslos abläuft, damit man sich Gedanken über eine Verschmelzung der Projekte machen kann. Bis dahin sollten die MicroProfile-Standards in Jakarta EE aufgenommen, aber nicht unter dem Dach von Jakarta EE entwickelt 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?

Ich denke, Jakarta EE sollte deutlich modularer werden.

Richard Monson-Haefel: Ich denke, Jakarta EE sollte deutlich modularer werden, was durch ein einfacheres, flexibleres Programmiermodell und die Übernahme des Java-SE-Modulsystems möglich wird. Modularität, sowohl durch das Programmiermodell, als auch durch entsprechendes Deployment, ist der beste Weg, um Cloud-native zu werden. Es eröffnet aber auch Wege zu allen möglichen Arten von Deployments und Runtimes.

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?

Richard Monson-Haefel: Ich denke die Übernahme von MicroProfile-Standards ist Teil der Lösung für dieses Problem. Ich möchte hier noch einmal betonen, dass ich nicht der Meinung bin, MicroProfile sollte Teil des EE4J-Projektes (Jakarta EE) werden. Doch mit jedem Release von Jakarta EE, beginnend bei Jakarta EE 9, sollte ein Snapshot von MicroProfile in Jakarta EE enthalten sein. Wie bereits erwähnt ist der zweite Weg ein modularisiertes Programmier- und Deployment-Modell.

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?

Jakarta EE muss von der unterliegenden Runtime unabhängig bleiben.

Richard Monson-Haefel: Jakarta EE muss von der unterliegenden Runtime unabhängig bleiben. Nur so kann sichergestellt werden, dass es an keine andere Runtime gebunden ist, wenn neue Projekte (wie Kubernetes) wichtiger werden. Manche glauben, dass die native Integration von Dingen wie Kubernetes und Docker dringend notwendig ist, ich glaube das nicht. Kubernetes, Docker und andere Containerisierungslösungen sind Runtimes.
 
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?

Richard Monson-Haefel: Ich würde mich freuen, wenn alle 12 oder 18 Monate ein neues Release herauskommen würde. Soweit ich weiß ist aktuell das Zeil ein jährliches Release, aber dies könnte für eine Enterprise-Lösung ein wenig zu aggressiv sein. Die aktuellste Version der Java SE ist 10 und bald wird Java SE 11 veröffentlicht, während die am weitesten verbreitete Version Java SE 8 ist. Das zeigt recht deutlich, dass ein sehr schneller Release-Zyklus nichts ist, was die Community wollen oder gebrauchen kann.

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

Richard Monson-Haefel: Ich bin bereits sehr im Standardisierungsprozess involviert: Ich nehme daher aktiv an allen Sitzungen Jakarta EE Specification Committee teil, in denen wir derzeit den neuen Specification Process für Jakarta EE erarbeiten. Auch an den Sitzungen des Jakarta EE Steering Committees nehme ich regelmäßig teil, das für das Specification Committee und das Marketing Committee verantwortlich ist. Diese Bemühungen sind ziemlich zeitaufwendig, da wir dort grundlegende Dinge wie den Specification Process und Urheberrechtsfragen besprechen und bearbeiten.

Was tatsächliche Spezifikationen angeht, habe ich mich bereit erklärt, bei einigen Jakarta-API-Projekten auszuhelfen. Dazu zählen Eclipse-Projekte für Common Annotations, EJB und JAX-RS. Ich würde gerne an weiteren Projekten mitarbeiten, etwa JMS und CDI, aber das ist derzeit leider nicht möglich.

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

Richard Monson-Haefel: Die Community sollte die Arbeit mit Java EE 8 fortsetzen, das funktional identisch mit Jakarta EE 8 sein wird. Mit Jakarta EE 9 wird dann der Wandel hin zu einer einfacheren, leichtgewichtigeren und flexibleren Plattform beginnen, was allerdings nicht vor Mitte oder Ende 2019 passieren wird.

Obwohl Java EE 8 nicht perfekt ist, ist es doch stabil, weit verbreitet und standardisiert.

Obwohl Java EE 8 nicht perfekt ist, ist es doch stabil, weit verbreitet und standardisiert. Das Gleiche gilt auch für Jakarta EE, dessen Doppelgänger. Java/Jakarta EE 8 ist das Ergebnis von 20 Jahren Echtzeitentwicklung und -erfahrung. Daher hat diese Technologie bereits Probleme gelöst, die andere Frameworks noch nicht einmal auf dem Schirm haben.

Der Schlüssel für ein erfolgreiches Deployment von Java/Jakarta EE 8 ist für Entwickler, nur das zu nutzen, was sie wirklich brauchen, und den Rest zu ignorieren. Java/Jakarta EE 8 ist eine Werkzeugkiste, in der alles enthalten ist, was man braucht. Man braucht allerdings nicht alle Werkzeuge auf einmal, doch wenn man eines braucht, ist es da.

JAXenter: Vielen Dank für das Interview!

Monsol-Haefel Jakarta EERichard Monson-Haefel is a OpenEJB co-founder, Java EE Author, JCP EC alumni, ex-Gartner Analyst, Father, Husband. Proud member of @Tomitribe. Ready to help shape #JakartaEE. Follow him on Twitter @rmonson.
 
 
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: