Das CN4J-Profil als gemeinsames EE- und MP-Profil – ein Vorschlag

Die Java EE-Plattform wurde vor einiger Zeit auf die Jakarta EE-Plattform umgestellt. Etwa zur gleichen Zeit spaltete sich eine Gruppe von Java-EE-Anbietern ab und startete MicroProfile; eine Plattform, die zunächst nur einige Java-EE-APIs enthielt, später aber um ursprünglich für Java EE 8 geplante APIs (wie Config, Health und JWT) erweitert wurde.

Da MicroProfile und Jakarta EE jetzt beide bei Eclipse vertreten sind und beide wieder ungefähr alle dieselben Anbieter umfassen, gibt es eine steigende Nachfrage, sich den Bemühungen irgendwie anzuschließen. Wir haben in unserer letzten Umfrage danach gefragt, wo die meisten Befragten gerne eine Übereinstimmung sehen würden.

Da stellt sich die Frage, wie man das genau macht. MicroProfile verwendet bereits Jakarta EE-APIs, und es besteht ein starker Wunsch, MicroProfile Config in Jakarta EE zu verwenden. Dies würde jedoch zu einer zirkulären Abhängigkeit führen, die möglicherweise nicht ideal ist. Eine Option im Software-Engineering, um zirkuläre Abhängigkeiten aufzubrechen, besteht darin, die gemeinsamen Abhängigkeiten in ein neues, gemeinsam genutztes Modul auszugliedern.

Das Herausrechnen der Jakarta-APIs, die MicroProfile verwendet, und der MicroProfile-API, die Jakarta verwenden möchte, würde ein Bild wie dieses zeichnen:Oben sehen wir das CN4J-Profil, wobei CN4J für Cloud Native for Java steht. Dies ist der Name der Allianz, die geschaffen wurde, um MicroProfile auszurichten. Alle APIs in diesem Profil würden berücksichtigen, dass sie sowohl von MicroProfile als auch von Jakarta EE verwendet werden, und würden sich daher entsprechend weiterentwickeln.

Auf der linken Seite sehen wir die aktuellen MicroProfile-APIs, die Teil der MicroProfile-Plattform und alle exklusiv für MicroProfile sind. Ähnlich sehen wir rechts eine Auswahl der Jakarta EE-Webprofil-APIs (einige Abhängigkeiten mehrerer APIs, wie Authentifizierung und Interceptors, werden ausgelassen) .

In Zukunft könnten einige zusätzliche APIs auf das CN4J-Profil umziehen, aber das sollten natürlich nicht zu viele sein. Im Moment ist Jakarta Security ein Kandidat (in der Praxis basiert @RolesAllowed/JWT nicht selten auf Jakarta Security).

Beachten Sie, dass es sich bei dem oben Gesagten um einen persönlichen Vorschlag handelt, der zwar diskutiert wird, aber in keiner Weise von den MicroProfile- oder Jakarta EE-Arbeitsgruppen oder der CN4J-Allianz unterstützt wird. Es soll als Grundlage für weitere Diskussionen dienen.