Suche
Unsere Interview-Serie zu Jakarta EE: Reza Rahman

Jakarta EE im Klartext: „Eine der größten Herausforderungen für Java EE ist der Aufbau einer Community“

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 Reza Rahman, Senior Vice President von AxonIQ & Java EE Guardian. 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 Reza Rahman, Senior Vice President von AxonIQ & Java EE Guardian. Ab geht die Reise ins Jakarta-EE-Universum!

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

Reza Rahman: Auf jeden Fall, das steht außer Frage. Das Unterfangen sollte allerdings erst dann umgesetzt werden, wenn die Modularisierung von Jakarta EE vollständig ist. Der Mangel an Modularisierung war nämlich immer einer der Gründe dafür, dass man in Bezug auf Java EE immer konservativ war und weder aktuellen Trends nachging noch experimentelle Technologien implementiert hat.

Eine Verschmelzung von MicroProfile und Jakarta EE sollte er st nach der Modularisierung von Jakarta EE stattfinden.

Obwohl einige Features von MicroProfile extrem gut sind (die Configuration-Funktion ist bspw. sehr wertvoll, sogar außerhalb des Microservices-Kontextes), ist es noch immer fragwürdig, ob Microservices für die meisten Anwendungen sinnvoll sind. Wenn die Modularisierung von Jakarta EE nicht zeitnah umgesetzt werden kann, wäre ich dafür die MicroProfile APIs in einem speziellen Profil unterzubringen. Dieses könnte man Microservices Profile nennen und gesondert anbieten, es also nicht zum Teil des Web- oder Full-Profils zu machen. Das Gleiche gilt natürlich auch für interessante Eclipse-Projecte wie JNoSQL.

Ich persönlich würde mich freuen, wenn man die Modularisierung in Jakarta EE durch JPMS und standardisierte Optionen für Thin WARs, Fat JARs und Hollow Uber JARs umsetzen würde. Open Liberty leistet hervorragende Arbeit in dem Bereich, auch wenn die Unterstützung für JPMS noch nicht umgesetzt wurde. Eine Konsequenz der Unterstützung von Modularität ist meiner Meinung nach, so viele APIs wie möglich eigenständig und Java-SE-freundlicher zu machen. Ein weiterer Schlüssel zur Modularisierung ist die Erschaffung eines Servlet-only Kernprofils, das nicht das CDI enthält. Der Kern könnte sogar noch kleiner sein, etwa wie eine Netty-artige Netzwerkprotokollebene, die dann ein Subset der derzeitigen Servlet-Funktionalität darstellen 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?

Reza Rahman: Cloud-native ist ein sehr vager Begriff. Ich würde sagen, Java-EE-8-Anwendungen sind bereits jetzt ziemlich „Cloud-native“. Abgesehen von dieser Diskussion würde ich sagen, dass das, was einige Puristen „Cloud-native“ nennen, durch die Standardisierung von MicroProfile und ein paar Features erreicht werden kann, die bereits seit Langem gewünscht werden. Dazu gehören umfangreichere Konfigurationsmöglichkeiten (via API und auf Runtime-Ebene), eine portablere Konfiguration für Dinge wie Java-EE-Nebenläufigkeitsressourcen und eben die Modularisierung. Es gibt auch ein paar Dinge, die in MicroProfile bereits enthalten sind und noch hinzugefügt werden könnten: Cloud Storage, dynamische Registry/Discovery und Client-seitiges Load-Balancing etwa.

Derzeit habe ich die Befürchtung, dass wir uns zu sehr auf MicroProfile konzentrieren. Wir vergessen allzu leicht, dass auch andere Teile von Java EE dringender Überarbeitung bedürfen. Das sind meist nur kleine Verbesserungen, doch sind diese nicht minder wichtig. Das gilt zum Beispiel für APIs wie EJB (das wir durch CDI ersetzen sollten), JMS, Java EE Concurrency, Java EE Security, JPA, JTA, JAX-RS, JSON-P und JSON-B. Auch kleinere Teile von Java EE könnten zumindest bessere CDI-Erweiterungen von Drittanbietern nutzen, etwa JCache, JCA, JavaMail und JBatch. Es gibt auch immer noch APIs, deren Interoperabilität mit Java SE 8 zu wünschen übrig lässt (etwa für Dinge wie wiederholbare Annotationen und Completable Future).

Java EE könnte eine kleine Frischekur in Sachen rekativer Programmierung brauchen.

Eine weitere sehr prominente Sache, die ich hier nennen könnte, wäre die Unterstützung von nicht-blockierendem I/O in JPA/JDBC via Completable Future. Java EE könnte wirklich eine kleine Frischekur in Sachen reaktiver Programmierung und Reactive Streams (inklusive Servlet API) gebrauchen. Und natürlich wird es Zeit, die MVC-Spezifikation final fertigzustellen (und sicherzustellen, dass sie reaktiv ist).

Ich hoffe, dass diese Dinge die nötige Aufmerksamkeit erfahren und nicht nur MicroProfile zukünftig im Fokus steht. Ich persönlich werde mich jedenfalls dafür einsetzen.

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

Reza Rahman: Meiner Meinung nach ist Java EE bereits ziemlich gut für den Einsatz in der Cloud aufgestellt. Ich habe hierzu sogar auf der JavaOne im letzten Jahr einen Vortrag gehalten. Die Antwort, nach der manche Leute suchen, ist die gleiche, wie auf die Frage, wie man Java EE für Cloud-native Leute schmackhafter machen kann. Ich denke allerdings, dass es viel wichtiger wäre, wenn endlich jemand eine Serverless-Lösung erschaffen würde, die auf Java EE basiert. das Programmiermodell von Java EE ist in meinen Augen perfekt dafür geeignet.

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?

Reza Rahman: Für die meisten Organisationen und ihre Microservices-Ambitionen ist Java EE, das sage ich ganz ehrlich, bereits sehr gut geeignet. In meinem Talk auf der JavaOne 2015 habe ich dieses Thema bereits ausführlich erläutert. Im Grunde geht es auch hierbei um die Frage, wie man Java EE „Cloud-native“ machen 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?

Reza Rahman: Ich denke schon. Docker und gerade Kubernetes sind sogar unabhängig von Microservices und der Cloud derzeit extrem wichtig. Ich denke aber, dass diese Geschichte sich mit Ideen umsetzen lässt, die in MicroProfile bereits im Entstehen begriffen sind.

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

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?

Reza Rahman: Meiner Erfahrung nach waren langsame Release-Zyklen eines der Hauptprobleme von Java EE. Ich bin definitiv für schnellere Release-Zyklen und glaube, dass die Modularisierung der Schlüssel hierzu ist. Am besten wären wohl vierteljährliche Releases für Java EE – so wie es bei MicroProfile schon lange Gang und Gäbe ist.

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

Docker und gerade Kubernetes sind sogar unabhängig von Microservices und der Cloud derzeit extrem wichtig.

Reza Rahman: Der Entwicklungsprozess ist nur ein Teil der Gleichung. Die größten Herausforderungen für Java EE sind der Aufbau einer Community, der tatsächliche Einsatz und das Anlernen von Entwicklern. Außerdem braucht es Java EE Evangelists und Advocates. In Sachen Advocacy geht es gar nicht nur um das Werben für Java EE, sondern auch darum sicherzustellen, dass alle „Player“ die richtigen Dinge zur richtigen Zeit tun. Bei den Java EE Guardians sind wir uns einig, dass wir diesen Auftrag auch in der Ära nach Sun und Oracle zum Fokusthema machen sollten. Ich werde also dafür sorgen, dass die Java EE Guardians diese Ziele weiterhin fest im Blick hat.

Ganz persönlich werde ich natürlich auch ein Auge auf alles haben, das mit Java EE, Jakarta EE oder MicroProfile zu tun hat. Natürlich gibt es auch Technologien, die mich ganz subjektiv interessieren. Dabei geht es meistens um bereits existierende Dinge wie der Frage, welche CDI-Alternativen es für EJB, JMS, Java EE Concurrency und Java EE Security gibt.

Auch wenn ich selbst womöglich nicht direkt involviert sein werde, wird meine Firma AxonIQ dabei helfen, CQRS und Event Sourcing für MicroProfile – und damit schließlich auch für Jakarta EE – umzusetzen.

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

Reza Rahman: Ich würde sagen die Rolle der Community bleibt unverändert. Die Mitglieder müssen sich auf dem Laufenden halten und – je nach Zeitbudget und Interesse – sich einfach beteiligen. Ein Weg dies zu tun, ist ein Engagement bei den Java EE Guardians. Dazu reicht es praktisch, den Java EE Guardians auf Twitter zu folgen.

Ich denke wir leisten ganz gute Arbeit dabei, die Community über aktuelle Ereignisse zu informieren. Läuft jemandem dabei etwas Interessantes über den Weg, kann er sich sofort daran beteiligen.

JAXenter: Vielen Dank für das Interview!

Reza Rahman is Senior Vice President at AxonIQ. He is the author of the popular book EJB 3 in Action. Reza has long been a frequent speaker at Java User Groups and conferences worldwide including JavaOne and Devoxx. He has been the lead for the Java EE track at JavaOne as well as a JavaOne Rock Star Speaker award recipient. Reza is an avid contributor to industry journals like JavaLobby/DZone and TheServerSide. He has been a member of the Java EE, EJB and JMS expert groups over the years. Reza implemented the EJB container for the Resin open source Java EE application server. He helps lead the Philadelphia Java User Group.

Reza has over a decade of experience with technology leadership, enterprise architecture, application development and consulting. He has been working with Java EE technology since its inception, developing on almost every major application platform ranging from Tomcat to JBoss, GlassFish, WebSphere and WebLogic. Reza has developed enterprise systems for well-known companies like eBay, Motorola, Comcast, Nokia, Prudential, Guardian Life, USAA, Independence Blue Cross, Anthem, CapitalOne and AAA using Java EE and Spring.

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: