Unsere Interview-Serie zu Jakarta EE: David Heffelfinger

Jakarta EE im Klartext: „Eclipse MicroProfile könnte zu einer Art Innovationszweig für Jakarta EE werden“

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 erster Gast ist David Heffelfinger, Jakarta EE Consultant & Instructor. 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 erster Experte ist Jakarta EE Consultant & Instructor David Heffelfinger. Ab geht die Reise ins Jakarta-EE-Universum!

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

Eclipse MicroProfile könnte sich in Zukunft als so eine Art ‚Innovationszweig‘ für Jakarta EE herauskristallisieren.

David Heffelfinger: Auch wenn ich nicht komplett gegen diese Idee bin, muss man bedenken, dass Java EE traditionell ein Mechanismus für die Standardisierung war. Das Java Persistance API (JPA) entstand aus den verfügbaren Tools für objektrelationales Mapping, das Framework JavaServer Faces (JSF) hingegen brachte die Integration von Ideen verschiedener MVC Frameworks hervor. In Java EE selbst passierte daher vergleichsweise wenig Innovation.

Eclipse MicroProfile könnte sich in Zukunft als so eine Art „Innovationszweig“ für Jakarta EE herauskristallisieren, womit ich meine, dass man bei MicroProfile neue Spezifikationen zunächst auf experimentelle Weise hinzufügt und sie dann, wenn sie stabil sind, auch in Jakarta EE implementiert. Dies könnte dazu führen, dass Jakarta EE noch mehr Stabilität garantieren kann, als das bei Java EE der Fall war, während MicroProfile die Plattform für Entwickler darstellen würde, die innovative neue Ideen hinzufügen wollen.

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?

David Heffelfinger: Es ist vielleicht noch ein wenig zu früh, um das mit Bestimmtheit zu sagen, doch es gab bereits Diskussionen darüber, das Modulsystems aus Java 9 zu nutzen.

Die Idee ist es, sich vom Konzept der Anwendungsserver zu verabschieden. Stattdessen werden Runtimes zur Build-Zeit erstellt, in denen Implementierungen verschiedener Jakarta-EE-Spezifikationen miteinander verknüpft werden. Wenn wir diese Ideen umsetzen könnten, würden Jakarta-EE-Anwendungen deutlich kleiner werden und sehr viel weniger Ressourcen verbrauchen, als dies noch mit Java EE der Fall war. Es wäre zudem einfacher, diese Anwendungen dann in Container zu packen und sie in der Cloud zu deployen.

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

David Heffelfinger: Vielleicht, indem man einige der MicroProfile APIs wie Config, Fault Tolerance und Health Check implementiert. Man sollte außerdem auf Java-9-Module setzen, um Runtimes zu erstellen, die nur jene APIs enthalten, die in der jeweiligen Anwendung auch wirklich genutzt werden.

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?

David Heffelfinger: Ich denke, dass Java EE bzw. Jakarta EE schon jetzt sehr gut in diesem Bereich aufgestellt ist. Es gibt einige entsprechende Runtimes für Java EE und Jakarta EE, die für die Enwicklung und das Deployment von Microservices genutzt werden können, zum Beispiel Apache Tomee, Websphere Liberty und Payara Micro. Auch hier würde die Umstellung auf des Modulsystem von Java 9 dafür sorgen, Jakarta-EE-Anwendungen leichtgewichtiger und somit für die Nutzung im Microservices-Kontext optimaler zu gestalten.

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 fände es nicht gut, wenn Jakarta EE an ein bestimmtes Tool zur Orchestrierung von Containern gebunden wäre.

David Heffelfinger: Einer der grundlegenden Voteile von Java EE bzw. Jakarta EE ist, dass die spezifischen Eigenschaften von Technologien abstrahiert werden, mit denen wir arbeiten. Dadurch entsteht die Flexibilität mit wenigen oder gar keinen Änderungen am Code selbst, Technologien zu wechseln. Die Java Virtual Machine (JVM) abstrahiert zum Beispiel das Betriebssystem, sodass die gleiche Code-Basis auf Windows-, Mac- und Linux-Servern läuft. Java Database Connectivity (JDBC) abstrahiert das relationale Datenbankanagementsystem (RDBMS), wodurch wir nach Belieben und mit minimalem Einfluss auf unseren Code den Datenbankanbieter wechseln können. Dieses Muster sieht man in der Java-Welt immer und immer wieder.

Aus diesem Grund würde ich es nicht gut finden, wenn man Jakarta EE an ein bestimmtes Container-Orchestrierungstool binden würde. In diesem Zusammenhang wäre es meiner Meinung nach besser, wenn die Arbeit mit verschiedenen Orchestrierungstools möglich wäre.

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?

David Heffelfinger: Vielleicht wäre so eine Art Zwischending das Richtige. Java EE wird traditionell im kommerziellen Umfeld eingesetzt und dort ist man eher konservativ und risikoscheu. Dies ist der Grund dafür, dass man in einem solchen Umfeld dazu neigt, den Technologie-Stack nicht besonders oft zu aktualisieren.

Gäbe es nun regelmäßige Releases von Jakarta EE, würden viele Organisationen wohl Versionen nutzen, die drei oder vier Versionen hinterherhängt. Vielleicht wäre ein jährliches Jakarta EE Release ein guter Kompromiss.

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

David Heffelfinger: Wegen einer Vielzahl anderer Verpflichtungen hatte ich bislang nicht wirklich Gelegenheit, sehr aktiv am Entwicklungsprozess von Jakarta EE mitzuwirken. Taditionell habe ich aber für Java EE immer den Fokus darauf gelegt, Entwickler über die neuesten Features der Technologie auf dem Laufenden zu halten, indem ich Dokumentationen geschrieben, Online- und On-Site-Trainings angeboten sowie auf Konferenzen gesprochen habe. Dies möchte ich in Bezug auf Jakarta EE auch in Zukunft tun.

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

Vielleicht wäre ein jährliches Jakarta EE Release ein guter Kompromiss.

David Heffelfinger: Dass Jakarta EE eine wirklich offene Spezifikation wird, haben viele Mitglieder der Java EE Community lange herbeigesehnt. Nun, da es endlich soweit ist, sollte die Community auch eine aktivere Rolle übernehmen, indem sie an neuen Spezifikationen mitarbeitet, frühe Versionen neuer Jakarta-EE-Spezifikationen testet, Blogs schreibt und allgemein Jakarta EE und das Wissen darum verbreitet.

Wenn wir nun alle einfach nur abwarten und schauen, wohin sich Jakarta EE entwickelt, jetzt da es endlich komplett offen ist, wird einfach nichts passieren. Wenn wir uns zusammenraufen und alle gemeinsam daran arbeiten, können wir Großartiges erreichen.

JAXenter: Vielen Dank für das Interview!

David Heffelfinger ist ein unabhängiger Consultant mit dem Fokus auf Java, Java / Jakarta EE und J2EE. Er ist Autor verschiedener Bücher zum Thema Java und artverwandter Technologien („Java EE 7 Development with NetBeans 8“, „Java EE 7 with GlassFish 4 Application Server“ und weitere). Er wurde zudem von TechBeacon als einer der 39 „Java leaders and experts to follow on Twitter“ geführt. David hat sehr viel Erfahrung mit der PrimeFaces-JSF-Component-Bibliothek und ist regelmäßig als Speaker auf Konferenzen wie der JavaOne vertreten. Er hat über 20 Jahre Erfahrung in den Bereichen Software-Architektur, -Design und -Entwicklung. Java war Davids erste Programmiersprache, mit der er seit 1996 arbeitet. Er hat an vielen großen Enteprise-Java-Projekten für verschiedene Kunden gearbeitet, unter anderem für das US Department of Homeland Security, das Department of Housing and Urban Development (HUD), Freddie Mac, Fannie Mae und das US Department of Defense. Auf Twitter ist er unter dem Handle @ensode zu finden.
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: