Spezifikation / PlattformOrientierungJakarta EE 11

Jakarta Enterprise Landkarte: Plattform, Profile, Spezifikationen, Runtimes

Jakarta EE ist kein einzelnes Framework, sondern eine standardisierte Enterprise-Java-Plattform aus Profilen und einzelnen Spezifikationen. Die konkrete Laufzeit kommt von Implementierungen wie GlassFish, Open Liberty, WildFly, Payara oder TomEE.

Einordnung
Spezifikation / Plattform
Enterprise-Rolle
Diese Landkarte hilft dir, alte Java-EE-Systeme und moderne Jakarta-EE-Anwendungen sauber zu lesen: Was ist Standard? Was ist Runtime? Was ist Fachcode? Was ist Vendor-Konfiguration?
Diagramm zu Jakarta Enterprise Landkarte: Plattform, Profile, Spezifikationen, Runtimes

Fachliches Verständnis

Diese Landkarte hilft dir, alte Java-EE-Systeme und moderne Jakarta-EE-Anwendungen sauber zu lesen: Was ist Standard? Was ist Runtime? Was ist Fachcode? Was ist Vendor-Konfiguration? In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.

Kernkonzepte

  • Platform Profile enthält die breite Enterprise-Plattform.
  • Web Profile fokussiert Webanwendungen.
  • Core Profile zielt auf kleinere Microservice-Runtimes.
  • Einzel-Spezifikationen wie CDI, REST, Servlet, Persistence oder Messaging definieren Verträge.
  • Runtimes implementieren diese Verträge und liefern Betriebseigenschaften.

Typische Einsatzfälle

  • Modernisierung von Java EE 7/8 nach Jakarta EE 10/11.
  • Bewertung, ob ein System Web Profile, Core Profile oder volle Platform braucht.
  • Trennung von portierbarem Fachcode und serverabhängiger Konfiguration.

Technisches Beispiel

text
Jakarta Enterprise Merksatz

Spezifikation: definiert Standard und API-Vertrag.
Framework: ruft deinen Code nach Lifecycle und Konvention auf.
Library: wird gezielt von deinem Code verwendet.
Runtime: implementiert Spezifikationen und betreibt Deployments.

Beispiel:
Jakarta RESTful Web Services = Spezifikation/Framework-API
Jersey, RESTEasy, CXF = Implementierungen
Open Liberty, WildFly, GlassFish = Runtime/Server
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.

Enterprise-Fallen

  • Jakarta EE mit einem konkreten Server verwechseln.
  • Spezifikation und Implementierung vermischen.
  • Alte javax.*-Pakete unkoordiniert mit jakarta.* mischen.

Legacy-Modernisierung

Java EE 8 nutzt javax.*; Jakarta EE 9+ nutzt jakarta.*. Migrationen sollten kontrolliert über Dependencies, Bytecode, Imports, Tests und Deployment Descriptor erfolgen.

Vertiefung: Review-Fragen für Senior-Entwickler
  • Welche Spezifikation ist hier wirklich nötig?
  • Welche Runtime-Funktion wird genutzt und ist sie portabel?
  • Wo liegt die Transaktionsgrenze?
  • Sind API-Verträge, DTOs und Domain-Modelle getrennt?
  • Ist der Code ohne Application Server testbar?
Index