Interview mit Sebastian Daschner über sein "Proposal on Jakarta EE’s innovation & relationship with MicroProfile"

„Wir sollten die Technologien aus Jakarta EE und MicroProfile als eine Familie betrachten“

Hartmut Schlosser

Sebastian Daschner

Java EE war stets der offizielle Enterprise-Standard für Java. Nun stehen mit Eclipse MicroProfile und Jakarta EE zwei Anwärter auf den Thron im Raum. Wie sollten sich Eclipse MicroProfile und Jakarta EE zueinander verhalten? Wie verhindert man auseinanderstrebende Entwicklungen? Im Interview mit Sebastian Daschner diskutieren wir einen Vorschlag.

Enterprise Java ist im Umbruch. Aus Java EE wurde Jakarta EE, dessen erstes Release kurz bevorsteht. Gleichzeitig werden im Eclipse-MicroProfile-Projekt in hoher Schlagzahl Innovationen entwickelt, um Java für Cloud- und Microservices-Szenarien fit zu machen. Unklar ist indes, wie sich Eclipse MicroProfile und Jakarta EE zueinander verhalten sollen. Sebastian Daschner hat mit einem Vorschlagspapier eine Diskussion über die Zukunft beider Projekte angestoßen. Wir haben nachgefragt.

Eclipse MicroProfile & Jakarta EE – der Stand der Dinge

JAXenter:  Eclipse MicroProfile und Jakarta EE zielen beide darauf ab, die Entwicklung von Enterprise-Java-Anwendungen für Cloud-/Microservice-Kontexte zu vereinfachen. Historisch gesehen ist Jakarta EE der Nachfolger von Java EE. MicroProfile ist als neues Projekt zu einer Zeit entstanden, als Oracle wenig über die Zukunft von Java EE zu sagen hatte. Die Zukunft von Java EE ist jetzt allerdings klar – Jakarta EE unter der Schirmherrschaft der Eclipse Foundation. Warum brauchen wir dann überhaupt noch ein MicroProfile-Projekt? 

Sebastian Daschner: Zum aktuellen Zeitpunkt steht das erste Release von Jakarta EE noch aus, während MicroProfile bereits einige sehr wertvolle Projekte umfasst. Einige Dinge aus MicroProfile stammen direkt von Java EE – wie beispielsweise CDI oder JAX-RS. Einige andere wie Microprofile Config, Fault Tolerance, Metrics und OpenAPI sind neu und ergänzen Enterprise Java um sehr nützliche Technologien.

Eine pragmatische Herangehensweise in vielen Anwendungsprojekten ist es,  eine Kombination aus Java EE und MicroProfile zu nutzen, was auch von mehreren Laufzeitumgebungen wie Open Liberty oder Payara unterstützt wird.

JAXenter: Stand jetzt – worin bestehen die technologischen Unterschiede zwischen Eclipse MicroProfile und Jakarta EE?

Sebastian Daschner: Technologisch sind die Unterschiede minimal: Der Package-Name ist anders, und MicroProfile beinhaltet nicht so viele Komponenten wie Java EE / Jakarta EE. Andererseits kommen MicroProfile-Projekte üblicherweise mit demselben Look & Feel daher, bieten eine einheitliche Entwickler-Erfahrung und nutzen dieselben deklarativen Ansätze, die wir schon von Enterprise Java her kennen. Verglichen mit dem bisherigen Innovationstempo von Java-EE-Standards geht die Weiterentwicklung von MicroProfile-Projekten heute schneller voran. Außerdem sind wir gerade auf dem Weg zum ersten Jakarta EE Release, und dieses wird noch keine Neuerungen in den Spezifikationen enthalten, die Teil von Java EE waren.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: Java-Dossier für Software-Architekten 2019

Auf über 30 Seiten vermitteln Experten praktisches Know-how zu den neuen Valuetypes in Java 12, dem Einsatz von Service Meshes in Microservices-Projekten, der erfolgreichen Einführung von DevOps-Praktiken im Unternehmen und der nachhaltigen JavaScript-Entwicklung mit Angular und dem WebComponents-Standard.

 

Der Vorschlag

JAXenter: Auf der JCrete Unconference wurde ein Vorschlag entwickelt, wie MicroProfile und Jakarta EE in Zukunft zusammenarbeiten könnten. Wie kam es dazu? Wer steckt hinter den Ideen?

Wir brauchen einen Konsens, wie Incubator-Projekte entstehen und funktionieren sollen.

Sebastian Daschner: Ich wollte eine Diskussion über die Frage beginnen, wie der Innovationsprozess in Jakarta aussehen sollte. Obwohl Jakarta EE noch nicht erschienen ist, glaube ich, dass jetzt ein guter Zeitpunkt ist, um über einige wichtige Dinge nachzudenken: Wie soll Jakarta zukünftig weiterentwickelt werden? Was passiert mit der Arbeit, die im MicroProfile-Projekt geleistet wurde? Was wäre aus Anwendersicht das beste? Die Motivation war hauptsächlich, diese wichtigen Fragen auf die Agenda zu setzen.

Auf der JCrete-Konferenz gab es informelle Gespräche mit anderen Mitgliedern der Enterprise Java Community – von IBM und Red Hat. Wir haben einige Punkte diskutiert, die schließlich zu diesem Vorschlagspapier geführt haben.

JAXenter: Kannst du die wichtigsten Punkte kurz zusammenfassen?

Sebastian Daschner: Einer der Hauptpunkte ist, dass wir einen Konsens und letztlich einen wohl-definierten Prozess brauchen, wie Incubator-Projekte entstehen und funktionieren sollen. Der Grund dafür ist einfach, dass der größte Vorteil von Java EE immer schon die Konsistenz der Entwickler-Erfahrung war, die einheitliche Art und Weise, APIs zu nutzen, geteilte Design-Prinzipien wie Convention over Configuration, deklarative Ansätze und so weiter. Vor einem Jahr habe ich diese Prinzipien, die meiner Meinung nach Java EE zu einer großartigen Technologie gemacht haben, in einem Blogpost zusammengeschrieben: https://blog.sebastian-daschner.com/entries/jakarta-ee-design-principles. Um diese Vorteile nicht zu verlieren, braucht es meiner Meinung nach eine gemeinsame Richtung in den Jakarta-EE- und MicroProfile-Projekten.

Ein anderes Problem, das wir lösen müssen, ist die Tatsache, dass es bereits einige auseinanderstrebende Entwicklungszweige in Java EE und MicroProfile gibt – einfach deshalb, weil wir Java-EE-Spezifikationen wie JAX-RS oder CDI noch nicht weiterentwickeln können. Als Ergebnis davon gibt es jetzt den MicroProfile REST Client. Von einer rein technologischen Warte aus gesehen wäre es sicherlich sinnvoller gewesen, JAX-RS zu modernisieren – aber die Innovation auf den MicroProfile REST Client zu verschieben, war in der aktuellen Situation das einzige, was wir tun konnten. Genauso verhält es sich beim Config JSR, der auf dem MicroProfile Config-Projekt basieren und unter dem JCP entstehen sollte, jetzt aber unter Jakarta neu aufgelegt wurde.

Wenn wir das Thema Enterprise Java ein wenig weiter denken, so sehe ich Jakarta und MicroProfile aus technischer Perspektive als eine Familie, in der wir sicherstellen müssen, dass alle Spezifikationen von den Updates profitieren. Das bedeutet, dass alles in Jakarta früher oder später die Innovationen aus dem MicroProfile-Projekt aufgreifen müsste, beispielsweise im Bereich der Konfigurierung. Was wir diskutieren müssen, ist, wie wir diese Puzzlestücke zusammenbringen möchte, um für den Anwender eine einheitliche Entwicklungserfahrung mit gemeinsamen Design-Prinzipien, Package-Namen usw. zu erreichen.

Aus Sicht der Enterprise-Java-Idee ergibt es durchaus Sinn, die Menge der Technologien in Jakarta EE und MicroProfile als eine Familie zu betrachten.

Die Kontroverse

JAXenter: Nun wurden auf der Mailingliste Bedenken geäußert, dass der Vorschlag die Communities spalten könnte. Die Anwender müssten sich dann immer entscheiden, ob sie MicroProfile oder Jakarta EE unterstützen – oder beides. Siehst du auch die Gefahr einer Aufsplitterung? 

Sebastian Daschner: Ja und nein. Auf Ebene der Spezifikation sehen wir schon jetzt einige Anzeichen der Spaltung, beispielsweise am REST Client, Config JSR und dem Concurrency/Context-Propagation-Projekt. Für diese Entwicklungen gibt es auch gute Gründe. Aus Sicht des Anwenders sehe ich aber keine große Gefahr, da viele Projekte wie erwähnt ohnehin schon eine Kombination aus Java EE und MicroProfile einsetzen, einfach weil sie beide Technologien benötigen. Aus diesem Grund unterstützen viele Laufzeitumgebungen auch beide Technologien. Allerdings ergibt es aus Sicht der globalen Enterprise-Java-Idee durchaus Sinn, die Menge der Technologien beider Marken als eine zusammengehörige Familie zu betrachten, und wir sollten darüber nachdenken, wie diese in Zukunft zusammenwirken sollten, um ein einheitliches Bild zu gewährleisten.

JAXenter: Ein weiterer Kommentar betraf die Unabhängigkeit von Eclipse MicroProfile: In deinem Vorschlag gibt es ja die Idee, dass das MicroProfile-Projekt neue Standards von Jakarta EE übernimmt und im Zweifelsfall die eigenen Komponenten ersetzt. Wird MicroProfile dadurch nicht doch zu einem Inkubator degradiert? 

Sebastian Daschner: Da stimme ich nicht unbedingt zu. MicroProfile-Projekte sind bereits zu einem hohen Grad produktionstauglich und auch schon in echten Produktivszenarien im Einsatz. Ein Inkubator hingegen impliziert, dass die dort entwickelten Technologien noch nicht reif für die große Bühne sind – vergleichbar mit einer Beta-Version. Wenn es um die Frage der Innovationsgeschwindigkeit geht, dann ist es momentan sicherlich so, dass MicroProfile-Projekte viel schneller weiterentwicklet werden, was für den Fortschritt von Enterprise Java als Ganzes eine gute Sache ist.

JAXenter: Wie werden die Diskussionen weitergehen? Wird es bald eine Entscheidung zu diesem Thema geben? 

Sebastian Daschner: Ja, ich hoffe, dass wir irgendwann zu einer guten Entscheidung kommen werden. Abgesehen davon glaube ich, dass die – manchmal durchaus hitzigen – Debatten wertvoll sind, da sie sehr wichtige Punkte aufgreifen, beispielsweise was die Namenskonventionen und Markenperspektiven anbelangt. Genau das war mein ursprüngliches Ziel: Es geht nicht darum, alle von einer bestimmten Lösung zu überzeugen, sondern einfach darum, alle mit ins Boot zu holen und so viele valide Argumente wie möglich zu sammeln, um eine vernünftige Marschrichtung einschlagen zu können. Und ich glaube, dass jetzt ein guter Zeitpunkt ist, über diese Dinge nachzudenken.

 JAXenter: Vielen Dank für dieses Interview!

Sebastian Daschner is a self-employed Java consultant, author and trainer and is enthusiastic about programming and Java (EE). He is the author of the book ‘Architecting Modern Java EE Applications’. Sebastian is participating in the JCP, helping forming the future standards of Java EE, serving in the JAX-RS, JSON-P and Config Expert Groups and collaborating on various open source projects. For his contributions in the Java community and ecosystem he was recognized as a Java Champion, Oracle Developer Champion and double 2016 JavaOne Rockstar. Besides Java, Sebastian is also a heavy user of Linux and container technologies like Docker. He evangelizes computer science practices on https://blog.sebastian-daschner.com, his newsletter, and on Twitter via @DaschnerS. When not working with Java, he also loves to travel the world — either by plane or motorbike.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. #java #eclipse #devops #machinelearning #seo. Zum Lächeln bringen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: