Ein Vorschlag für mehr Innovation

MicroProfile vs. Jakarta EE: Diskussion um zukünftige Zusammenarbeit eröffnet

Hartmut Schlosser

© Shutterstock / gerasimov_foto_174

 

Sowohl Jakarta EE als auch Eclipse MicroProfile wollen die Entwicklung von Cloud-basierten Java-Enterprise-Anwendungen ermöglichen. Wie stehen beide Projekte zueinander? Ein neuer Vorschlag strebt eine Klärung an.

Eclipse MicroProfile & Jakarta EE – was bisher geschah

Wir erinnern uns: Das MicroProfile-Projekt entstand 2016 in einer Zeit, da Oracle die Kommunikation über Java EE eingestellt hatte. Unternehmen wie RedHat, IBM, Tomitribe, Payara und andere ergriffen die Initiative und stellten eine Untermenge von Java-EE-Komponenten zusammen, die auf die Entwicklung von Microservices-Anwendungen zugeschnitten waren. Das Projekt MicroProfile.io war geboren.

Seither ist viel passiert: Oracle hat Java EE als Open-Source-Projekt der Eclipse Foundation übergeben, allerdings mit der Auflage, den Namen zu ändern und den Namespace javax nicht zu verwenden. Unter dem neuen Brand Jakarta EE steht das Projekt kurz vor dem ersten großen Release Jakarta EE 8.

Auch das MicroProfile-Projekt ist bei Eclipse gelandet und hat im Juni 2019 die dritte Major-Version veröffentlicht. MicroProfile 3.0 ist voll kompatibel mit Jakarta EE 8 und nutzt die folgenden Spezifikationen als Programmiermodell für das Erstellen von Java Microservices:

MicroProfile 3.0 in der Übersicht / Quelle: MicroProfile.io

Das Dilemma

Da Jakarta EE in vielfacher Hinsicht auch auf die Entwicklung von Microservices getrimmt  werden soll, ist das Verhältnis zum MicroProfile-Projekt aktuell unklar, zumal der ursprüngliche Motivationsgrund – die Stagnation des Java-EE-Projektes – nicht mehr existiert.

Einige sehen MicroProfile deshalb als Inkubator für Jakarta EE, in dem experimentelle Projekte entstehen können, die bei Bewährung dann in die offizielle Jakarta-EE-Spezifikation aufgenommen würden. Andere wünschen sich eine größere Eigenständigkeit von MicroProfile.

Ein Vorschlag über die künftige Richtung und Zusammenarbeit beider Projekte hat Sebastian Daschner nun auf der Mailing-Liste (und seinem Blog) unterbreitet.

MicroProfile & Jakarta EE Proposal

Entstanden ist der Vorschlag nicht im stillen Kämmerlein, sondern ist Ergebnis von Diskussionen einiger Teilnehmer der JCrete Unconference. Dabei wurden die folgenden Anforderungen formuliert:

  • Ausgangspunkt ist der Wunsch, Enterprise Java weiter voranzubringen. Dafür müsse die Möglichkeit geschaffen werden, Innovationen einzubringen, ohne dass diese gleich zu Standards würden.
  • Nötig sei also ein Inkubator, darüberhinaus aber auch ein Prozess, um Inkubator-Projekte auf einen gemeinsamen Nenner zu bringen – eine technologische Baseline, auf die sich alle Projekte beziehen können.
  • MircoProfile sei im Ökosystem bereits als produktionstaugliche Technologie verankert, sodass das Projekt von den meisten Nutzern nicht als Inkubator verstanden werde.

Der Vorschlag lautet nun, eine Jakarta-Dachspezifikation zu etablieren, die die Standards der Basline enthalten soll – in Analogie zu der bisherigen Java EE Umbrella-Spezifikation. Außerdem sollen Jakarta-Inkubatoren eingerichtet werden, in denen experiementelle Projekte entstehen können. Diese Inkubator-Projekte sollen sich auf eine spezifische Version im Jakarta Baseline Branch beziehen und die selben Design-Prinzipien wie Jakarta-EE-Projekte einhalten sowie auch das jakarta-Java-Package nutzen, sodass der Umstieg von Inkubator-Dependencies zu Jakarta-EE-Spezifikationen einfach möglich wird.

Jedes Inkubator-Projekt soll eine Spezifikation vorlegen, die konkret einer Gruppe von Implementierern zugewiesen wird, zudem eine Dokumentation und Code-Beispiele zum schnellen Nachvollziehen. Davon unberührt wird das MicroProfile-Projekt wie bisher weiterentwickelt. Geeignete Innovationen werden in Jakarta EE übernommen. Setzt Jakarta einen neuen Standard – etwa für die Config-Komponente -, wäre es sinnvoll, dass MicroProfile den Standard übernimmt.

Das folgende Diagramm – offenbar eine Skizze aus den JCrete-Diskussionen – soll den Vorschlag veranschaulichen:

Proposal on Jakarta EE’s innovation & relationship with MicroProfile, Quelle: Sebastian Daschner.

Jakarta EE – wie geht’s hier weiter?

Daschner nennt auch bereits einige Vorschläge für Jakarta Inkubator-Projekte:

  • Fault-tolerance: Dabei soll es um circuit breaker, timeouts, retries, fallbacks sowie Features aus dem MicroPofile-Projekt mp-fault-tolerance gehen.
  • Observability: Features aus den MicroPofile-Projekten mp-metrics, mp-open-tracing, mp-health.
  • Testing: Ideen aus den Projekten Arquillian, Spring Test und Testcontainer.
  • Reactive-streams & Messaging: Features aus den MicroPofile-Projekten mp-reactive-streams und mp-reactive-messaging.
  • LRA: Ansätze aus dem MicroPofile-Projekt mp-lra.
  • Open API: Features aus dem MicroProfile-Projekt mp-open-api.

Als neue Standards für Jakarta EE werden vorgeschlagen:

  • Jakarta-Config soll als neue Spezifikation in die Jakarta-Baseline aufgenommen werden und die Arbeiten am bisherigen Config JSR und MicroProfile Config miteinander vereinen.
  • Das Model-View-Controller-Projekt, das bisher unter dem JSR 371 entwickelt wurde.
  • JCache aus dem JSR 107.
  • Deployment-Spezifikationen: Dabei geht es um eine Standardisierung der Art und Weise des Deployments: etwa Deployment-Artefakte, die Bereitstellung von Bibliotheken, das Runtime-Directory-Layout, etc.

Aktualisierung bereits bestehender EE-Standards:

  • Concurrency: Vorgesehen ist eine Integration der Neuerungen aus den MicroProfile-Projekten mp-context-propagation und mp-fault-tolerance (Bulkheads).
  • Security: Integration der Neuerungen aus dem MicroProfile-Projekt mp-jwt-auth.
  • JAX-RS: Integration einiger Ansätze aus dem MicroProfile-Projekt mp-rest-client.

Diskussionen

Die Vorschläge werden aktuell auf der Jakarta EE Mailing-Liste kontrovers diskutiert. So sieht etwa Emmanuel Bernard die Gefahr, die Communities um MicroProfile und Jakarta EE mehr zu spalten als zu einen:

But you would be forking the communities and consumers (specs, frameworks etc) would need to decide to support the MP version or the Jakarta EE version, or worse both? That sounds like unnecessary complexity. This „I need to own the world of what I consume“ model is really at the root of a lot of Java EE problems. Emmanuel Bernard

Ken Finnigan kommentiert, dass die gemachten Vorschläge eine Beibehaltung der bisherigen MicroProfile-Prozesse quasi unmöglich machten:

I still don’t see how your proposal leaves MP „as it is today“ for several reasons.

You’ve proposed several specs from MP move over to Jakarta. Doing that means no work can happen in MP for those specs anymore otherwise it results in diverging specifications. When a Jakarta release is available for those specifications MP would need to discard it’s own version and use the Jakarta one, which would result in a Jakarta EE 9 style package rename headache for MP users every single time there was a new MP release that contained a switch from an MP to Jakarta spec of the same thing. Ken Finnigan

Daschner antwortet hierauf, dass der Vorschlag als Gegenmodell zu der Idee gedacht ist, MicroProfile gänzlich zu einem Inkubator für Jakarta EE zu machen:

I meant this as opposed to the idea of transforming MP to an / the incubator for Jakarta, which is an idea that quite a few in the community share / shared (including myself: [1]). I claim there is a need for a „rebase“ process, i.e. to integrate updates to the specifications such as CDI or Concurrency back to Jakarta EE. For now, these updates and innovation happen in MP. Integrating / merging / porting these ideas to Jakarta leaves MP intact w/r/t branding, or production-readiness, which is where a few in the community have expressed their concerns with, and where I do think this is valid. Sebastian Daschner

Wir werden sehen, wie die Diskussionen weiter gehen. Zur Entscheidung wird es hier voraussichtlich ohnehin nicht so bald kommen. Die gesamte Entwicklerkraft fließt derzeit in die Finalisierung von Jakarta EE 8, das für den 10. September 2019 angekündigt ist.

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: