Suche
Unsere Interview-Serie zu Jakarta EE: Mark Little, Vice President of Engineering bei Red Hat

Jakarta EE im Klartext: „Eine Fusion von MicroProfile und Jakarta EE würde aktuell beiden schaden“

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 Mark Little, Vice President of Engineering bei Red Hat. 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 Mark Little, Vice President of Engineering bei Red Hat. Ab geht die Reise ins Jakarta-EE-Universum!

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

Mark Little: Das ist eine häufig gestellte Frage und spätestens seit der JavaOne 2017 war die Antwort von uns bei Red Hat darauf konsequent: Wir hoffen, dass MicroProfile und Jakarta EE irgendwann verschmelzen werden, aber jetzt ist nicht der richtige Zeitpunkt. Jakarta EE ist immer noch dabei Fahrt aufzunehmen. Es gibt zum Beispiel noch keinen finalen Spezifikationsprozess, während MicroProfile sich hingegen schnell weiterentwickelt – allein in diesem Jahr wurden mehrere Versionen veröffentlicht.

Wenn MicroProfile und Jakarta EE jetzt verschmelzen würden, würden meiner Meinung nach beide darunter leiden: Der Fortschritt, der derzeit bei Jakarta EE gemacht wird, würde sich als erste Konsequenz verlangsamen. Man würde nämlich versuchen, mit etwas klar zu kommen, das sich deutlich schneller entwickelt, als man es im Hinblick auf Java EE gewohnt ist. Der Sekundäreffekt wäre, dass auch die Entwicklung von MicroProfile ins Stocken geraten würde.

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?

Nicht alles, was in Java EE 8 enthalten ist, muss zwangsläufig weiterentwickelt werden.

Mark Little: Wie MicroProfile zielt Jakarta EE darauf ab, sich von den Erfahrungen von Anbietern, Anwendern sowie einzelnen Mitwirkenden leiten zu lassen. Hinzu kommt der Wille, oft und frühzeitig neue Releases zu veröffentlichen. Java EE 8 ist zwar die Ausgangsbasis für die Community, aber das bedeutet nicht, dass wir alles in Java EE 8 weiterentwickeln werden, da diese Architektur auf einer anderen Reihe von Anwendungsfällen beruht.

Ich erwarte z.B., dass einige Dinge innerhalb von Java EE zunächst deprecatet und dann schließlich entfernt werden. Jakarta EE muss zudem ein viel größeres Feld abdecken, als Java EE. Das sehen wir bereits bei MicroProfile: Man schaue sich zur Inspiration ein paar der Sachen an, die wir dort machen. Das gibt ein ungefähres Bild davon ab, was noch alles für Jakarta EE geplant ist, etwa verschiedene Transaktionsmodelle und Fault Tolerance.

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

Mark Little: Der offensichtlichste Weg für diese Benutzer ist es, ihre Bedürfnisse und Anwendungsfälle in die Diskussionen der Community einzubringen. Ich arbeite seit fast drei Jahrzehnten auf die eine oder andere Weise mit Standards und die schlechtesten Standards sind diejenigen, die unabhängig von den Endnutzern entwickelt werden.

Bei Jakarta EE handelt es sich nicht um eine Normierungsorganisation wie etwa OASIS oder W3C. Wir entwickeln Software, die die Leuten einfach nehmen und nutzen können, doch in gewisser Weise ist es so noch wichtiger, dass uns die Nutzer mitteilen, ob wir auf dem richtigen Weg sind. Es ist mir ein wichtiges Anliegen, die Endnutzer in die verschiedenen Working Groups ebenso einzugliedern, wie die Personen, die aus den Use Cases dann konkrete Features ersinnen und diese schließlich in Form von Code umsetzen.

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

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?

Mark Little: Ich würde damit anfangen, eine weitere Seite aus dem MicroProfile Playbook aufzuschlagen: klein anfangen und nicht von Anfang an alle Spezifikationen vermischen. Als wir mit MicroProfile anfingen, war das CDI der Standardweg zur Erstellungen von Anwendungen, die Kommunikation fand via JAX-RS und JSON-P statt. Microservices brauchen mehr als nur das, wenn man echte Enterprise-Anwendungsfälle deployen will, aber diese drei sind ein gutes Fundament. Dann wird Schritt für Schritt darauf aufgebaut, wie wir das auch bei MicroProfile machen.

Wichtig ist es, nicht wahllos neue Funktionalitäten einzuführen, alle Features müssen auf einem klar definierten Bedürfnis basieren. Ist dies nicht der Fall, könnte es passieren, dass wir etwas, das eigentlich für Microservices gedacht ist, selbst zu einem Monolithen mit riesigen technischen Schulden wird.

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 würde schnellere Releases bevorzugen.

Mark Little: Auf jeden Fall. Heute kann man, ohne Kubernetes einzusetzen, nicht wirklich behaupten, Cloud-native zu sein. Es hat ganz Klar den „Orchestration War“ gegen Docker Swarm und weitere Konkurrenten gewonnen. Wenn man sich ansieht, was einige der Mitarbeiter bei Jakarta EE und MicroProfile machen, würde ich sagen, dass sie hier mit mir auf einer Wellenlänge sind. Man lese dazu etwa den Blog-Beitrag von meinem Kollegen Rafael Benevides.

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?

Mark Little: Ich würde schnellere Releases bevorzugen. Die Jakarta EE Community muss bald Konkretes veröffentlichen, damit die Nutzer sie ausprobieren und möglichst schnell Feedback geben können. Das gibt uns die Möglichkeit, schneller aus Fehlern und den aktuellen Entwicklungen der Industrie zu lernen.

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

Mark Little: Red Hat ist bereits stark involviert. Zusammen mit IBM war es eines der ersten Unternehmen, dass seine Mitarbeit an Jakarta EE bekannt gab. Sogar das Logo von Jakarta EE hat ein Designer von Red Hat entwickelt.

Was die Spezifikationen betrifft, so arbeiten wir bei Red Hat bereits an den aus Java EE bekannten CDI und Bean Validation. Aktuell sind wir aber auch dabei, andere wie JTA voranzubringen. Zudem sind wir auch stark an neuen Specs wie Config, Fault Tolerance und Metrics im Zuge des MicroProfile-Projektes beteiligt. Ich hoffe, sie werden in absehbarer Zeit auch in Jakarta EE aufgenommen.

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

Mark Little: Ich hoffe, dass sie es als eine positive Entwicklung und den Lohn der Arbeit ansehen, die sie und viele andere in den letzten zwei Jahrzehnten in den Enterprise-Java-Bereich investiert haben. Ich weiß, dass es einigen in der Community schwer fiel, sich mit Java EE zu beschäftigen, als der Java Community Process noch das Maß der Dinge war. Nun aber ist das Ganze unter dem Dach der Eclipse Foundation und es sollte diesbezüglich keine Hindernisse mehr geben.

JAXenter: Vielen Dank für das Interview!

Mark Little is a vice president of engineering at Red Hat, where he leads the technical direction, research, and development for Red Hat JBoss Middleware. Mark is also a professor at Newcastle University and Lyon University. Previously, Mark served as Red Hat’s SOA technical development manager and director of standards. Mark was also a chief architect and cofounder at Arjuna Technologies, a spin-off of HP, where he was a distinguished engineer. He has worked in the area of reliable distributed systems since the mid-’80s and holds a PhD in fault-tolerant distributed systems, replication, and transactions.
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: