Spezifikation / PlattformProfile11

Jakarta EE Platform 11

Die Jakarta EE Platform ist die große Dach-Spezifikation für klassische und moderne Enterprise-Anwendungen mit Web, CDI, Persistence, Security, Transactions, Messaging, Batch und Integrations-APIs.

Einordnung
Spezifikation / Plattform
Enterprise-Rolle
Sie ist sinnvoll, wenn eine Anwendung viele Enterprise-Fähigkeiten im selben Deployment braucht: Transaktionen, Datenbankzugriff, Messaging, Security, Timer, Batch und Webendpunkte.
Diagramm zu Jakarta EE Platform 11

Fachliches Verständnis

Sie ist sinnvoll, wenn eine Anwendung viele Enterprise-Fähigkeiten im selben Deployment braucht: Transaktionen, Datenbankzugriff, Messaging, Security, Timer, Batch und Webendpunkte. 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

  • Java SE 17 oder höher als Mindestbasis.
  • Records und Virtual-Threads-aware Runtime-Unterstützung gehören zu den EE-11-Neuerungen.
  • Jakarta Data 1.0 ergänzt Repository-orientierten Datenzugriff.
  • Optionale Spezifikationen wurden entfernt, um die Plattform klarer zu machen.

Typische Einsatzfälle

  • Monolithische Enterprise-Anwendung mit WAR/EAR-ähnlichem Funktionsumfang.
  • Portierbarer Code zwischen mehreren zertifizierten Runtimes.
  • Modernisierung ohne vollständige Spring- oder Quarkus-Neuschreibung.

Technisches Beispiel

xml
<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>11.0.0</version>
  <scope>provided</scope>
</dependency>

<!-- provided: Die Runtime liefert die Jakarta APIs zur Laufzeit. -->
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

  • Volle Platform wählen, obwohl Web oder Core Profile reichen.
  • Server-spezifische Features als Standard betrachten.
  • Deployment Descriptor ohne Not weiter pflegen.

Legacy-Modernisierung

Bei Java-EE-Legacy-Systemen zuerst genutzte APIs inventarisieren: EJB, JPA, JMS, JAX-RS, Servlet, JSF, JTA, Batch, Mail. Danach Zielprofil bestimmen.

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?
Jakarta EE Web ProfileJakarta EE Core ProfileIndex