Framework / RuntimeRuntimes2026 Orientierung

Jakarta Runtimes: GlassFish, Open Liberty, WildFly, Payara, TomEE

Runtimes implementieren Jakarta-Spezifikationen und liefern Deployment, Classloading, Ressourcen, Security, Monitoring und Betriebseigenschaften.

Einordnung
Framework / Runtime
Enterprise-Rolle
Die Runtime entscheidet über echte Produktionsfähigkeit, Konfiguration, Patches, Support und Cloud-Verhalten.
Diagramm zu Jakarta Runtimes: GlassFish, Open Liberty, WildFly, Payara, TomEE

Fachliches Verständnis

Die Runtime entscheidet über echte Produktionsfähigkeit, Konfiguration, Patches, Support und Cloud-Verhalten. 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

  • GlassFish als Referenz-/kompatible Implementierung.
  • Open Liberty mit modularer Feature-Konfiguration.
  • WildFly als Community Runtime aus JBoss-Tradition.
  • Payara als Enterprise-orientierte GlassFish-Familie.
  • TomEE als Tomcat-basierte EE-Runtime.

Typische Einsatzfälle

  • Serverauswahl für Migration.
  • Portabilität testen.
  • Betriebsmodell definieren.

Technisches Beispiel

xml
<server>
  <featureManager>
    <feature>jakartaee-11.0</feature>
    <feature>mpHealth-4.0</feature>
  </featureManager>

  <dataSource id="orders" jndiName="jdbc/orders"/>
</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

  • Nur auf API-Kompatibilität schauen.
  • Classloading, Patching und Observability ignorieren.
  • Vendor Features unmarkiert verwenden.

Legacy-Modernisierung

Von WebSphere/JBoss/GlassFish Legacy zuerst Betriebsfunktionen und verwendete Serverressourcen inventarisieren.

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