Java EE gegen J2EE gegen Jakarta EE

1. Einleitung

Schon mal was von Java EE gehört? Wie wäre es mit Java 2EE, J2EE oder jetzt Jakarta EE? Tatsächlich sind dies alles unterschiedliche Namen für dasselbe: eine Reihe von Unternehmensspezifikationen, die Java SE erweitern.

In diesem kurzen Artikel beschreiben wir die Entwicklung von Java EE.

2. Geschichte

In der ersten Java-Version waren Java-Unternehmenserweiterungen einfach Teil des Kern-JDK.

Als Teil von Java 2 im Jahr 1999 wurden diese Erweiterungen aus den Standard-Binärdateien herausgebrochen und J2EE oder Java 2 Platform Enterprise Edition wurde geboren. Es würde diesen Namen bis 2006 behalten.

Für Java 5 wurde J2EE 2006 in Java EE oder Java Platform Enterprise Edition umbenannt. Dieser Name würde bis September 2017 Bestand haben, als etwas Großes passierte .

Im September 2017 hat Oracle beschlossen, die Rechte für Java EE an die Eclipse Foundation zu vergeben (die Sprache gehört weiterhin Oracle) .

3. Im Übergang

Eigentlich ist die Eclipse Foundation rechtlich hatte Java EE umbenennen. Dies liegt daran, dass Oracle die Rechte an der Marke „Java“ besitzt.

Um den neuen Namen zu wählen, stimmte die Community ab und wählte: Jakarta EE. In gewisser Weise ist es immer noch J EE.

* Neuer Name bekannt gegeben

Dies ist jedoch immer noch eine sich entwickelnde Geschichte, und der Staub hat sich nicht vollständig gelegt.

Während Oracle beispielsweise den Quellcode als Open-Source-Version bereitstellte, wurde nicht die gesamte Dokumentation als Open-Source-Version bereitgestellt. Es gibt immer noch viele Diskussionen über diese Angelegenheit, da rechtliche Probleme es schwierig machen, Open-Source-Dokumentationen zu erstellen, die sich beispielsweise auf JMS und EJB beziehen.

Es ist noch nicht klar, ob sich die neue Eclipse Foundation-Dokumentation auf die Originale beziehen kann.

Seltsamerweise kann die Eclipse Foundation auch keine neuen Java-Pakete mit dem Javax- Namespace erstellen, aber sie kann neue Klassen und Unterklassen unter den vorhandenen erstellen.

Der Übergang bedeutet auch ein neues Verfahren zum Hinzufügen von Spezifikationen zu Jakarta EE. Um es besser zu verstehen, schauen wir uns an, wie dieser Prozess unter Oracle war und wie er sich unter der Eclipse Foundation ändert.

4. Die Zukunft

In der Vergangenheit brauchten wir drei Dinge, um ein Feature in „EE“ zu integrieren: eine Spezifikation, eine Referenzimplementierung und Tests. Diese drei Dinge könnten von jedem in der Gemeinde bereitgestellt werden, und ein Exekutivkomitee würde entscheiden, wann diese bereit sind, die Sprache zu erweitern.

Um den bisherigen Prozess besser zu verstehen, schauen wir uns genauer an, was JSRs, Glassfish und TCK sind und wie sie neue EE-Funktionen verkörpern .

Wir werden auch einen Blick darauf werfen, was uns in Zukunft erwartet.

4.1. Das JCP und jetzt das EFSP

In der Vergangenheit wurde der Prozess, durch den eine neue EE-Funktion geboren wurde, als Java Community Process (JCP) bezeichnet.

Java SE verwendet noch heute das JCP. Da EE seinen Eigentümer von Oracle auf die Eclipse Foundation geändert hat, haben wir dafür einen neuen und separaten Prozess. Es ist der Eclipse Foundation Specification Process (EFSP) und eine Erweiterung des Eclipse-Entwicklungsprozesses.

Es gibt jedoch einige wichtige Unterschiede, vor allem in Bezug auf „Transparenz, Offenheit, gemeinsame Belastung und Herstellerneutralität“. Die EFSP-Organisatoren stellen sich beispielsweise kollaborative Arbeitsgruppen vor, die herstellerneutral sind, einen Zertifizierungsprozess, der sich selbst bedient, und eine Organisation, die als Meritokratie agiert und regiert.

4.2. JSRs

In der JCP bestand der erste Schritt zum Hinzufügen einer Funktion zu EE darin, eine JSR- oder Java-Spezifikationsanforderung zu erstellen. Das JSR war ein bisschen wie die Schnittstelle für eine EE-Funktion. Das JCP-Exekutivkomitee überprüfte und genehmigte einen ausgefüllten JSR, und dann verschlüsselten JSR-Mitarbeiter ihn und stellten ihn der Community zur Verfügung.

Ein gutes Beispiel dafür war JSR-339 - oder JAX-RS -, das ursprünglich 2011 vorgeschlagen, 2012 von JCP genehmigt und schließlich 2013 veröffentlicht wurde.

Und während die Community während der Diskussion einer Spezifikation immer abwägen konnte, zeigte die Zeit, dass ein Implementierungsansatz - wie im Fall von JSR 310, java.time und Joda Time - dazu neigte, allgemein akzeptierte Funktionen und APIs zu erstellen .

Das EFSP spiegelt diese Code-First-Sichtweise in seinem erklärten Ziel wider: „Das EFSP basiert zunächst auf praktischen Experimenten und Codierungen, um zu beweisen, dass etwas in einer Spezifikation dokumentiert werden sollte.“

4.3. Glasfische

Als Teil des JCP benötigte ein JSR dann eine Referenzimplementierung. Dies ist ein bisschen wie die Klasse , die die Schnittstelle implementiert . Eine Referenzimplementierung hilft Entwicklern kompatibler Bibliotheken oder anderer Organisationen, die ihre eigene Implementierung der Spezifikation erstellen möchten.

Für Java EE-Funktionen verwendete das JCP Glassfish für seine Referenzimplementierungen.

Während diese Zentralisierung auf Glassfish den Erkennungsprozess für Implementierer vereinfachte, erforderte diese Zentralisierung auch mehr Governance und tendierte dazu, einen Anbieter einem anderen vorzuziehen.

Daher benötigt der EFSP keine Referenzimplementierung, sondern nur eine kompatible Implementierung. Einfach ausgedrückt, führt diese subtile Änderung dazu, dass Implementierungen innerhalb einer zentralen Architektur wie Glassfish von der Stiftung nicht versehentlich bevorzugt werden.

4.4. TCK

Schließlich forderte das JCP, dass EE-Funktionen mit dem Technology Compatibility Kit (TCK) getestet werden.

Das TCK war eine Reihe von Tests zur Validierung eines bestimmten EE-JSR. Einfach ausgedrückt, um Java EE zu erfüllen, muss ein Anwendungsserver alle seine JSRs implementieren und alle Tests auf dem angegebenen TCK bestehen.

Hier ändert sich nicht viel. Oracle hat sowohl das TCK als auch die EE-JSRs als Open-Source-Lösung bereitgestellt. Natürlich werden alle zukünftigen Dokumente und das TCK Open Source sein.

5. Schlussfolgerung

Java EE hat sich in diesen Jahren sicherlich stark weiterentwickelt. Es ist schön zu sehen, dass es sich weiter verändert und verbessert.

Es liegen viele Herausforderungen vor uns. Hoffen wir also auf einen reibungslosen Übergang.