Mercury Dokumentation

Dev Blog:OpenCms setzt auf Jakarta

Das Java-Ökosystem hat den Umstieg auf Jakarta EE abgeschlossen, und OpenCms zieht mit: OpenCms 22, geplant für Oktober 2026, läuft auf Tomcat 11 und Jakarta EE. Eine Legacy-Variante sorgt dafür, dass bestehende Installationen in ihrem eigenen Tempo folgen können.
Datum:
KW 29 / 2026
Von:
Alkacon Software

Wenn Sie die Entwicklung von OpenCms schon eine Weile verfolgen, haben Sie sich vielleicht gefragt, wann OpenCms auf Jakarta EE umsteigen würde. Dieser Zeitpunkt ist jetzt gekommen. Und die Geschichte, warum erst jetzt und nicht schon früher, ist vor allem eine Geschichte über Abhängigkeiten.

Wie jede Java-Anwendung baut OpenCms auf vielen externen Bibliotheken auf. In den letzten Jahren sind immer mehr davon auf Jakarta umgestiegen, zwei der größten aber nicht: Apache Solr, die Basis der OpenCms-Suche, und Vaadin, das Framework hinter der Workplace-Oberfläche.

Vaadin war der härtere Fall von beiden. Die OpenCms Workplace basiert auf einer Vaadin-Version, deren Open-Source-Entwicklung vor einigen Jahren eingestellt wurde; die letzten Open-Source-Releases unterstützen nur die alte Servlet-API, und nach dem Lizenzwechsel hatten wir die Hoffnung auf eine sauber konvertierte Jakarta-Version aufgegeben. Vaadin komplett abzulösen würde bedeuten, große Teile der Workplace neu zu schreiben, ein enormer Aufwand, den wir vermeiden wollten.

Eine Zeit lang war Abwarten schlicht die richtige Entscheidung. Wenn wir ehrlich sind, hatten wir insgeheim gehofft, dass sich die ganze Namespace-Spaltung irgendwann von selbst erledigt. Und Jetty 12 bot uns eine moderne, voll unterstützte Laufzeitumgebung, die weiterhin javax-basierte Anwendungen ausführen kann, also machten wir Jetty zu unserem Standard. Es gab mehr als ein Hindernis, und wenig Druck, das schwierigste davon anzugehen.

Das hat sich geändert. Mit Solr 10, erschienen im März dieses Jahres, hat die letzte unserer großen Abhängigkeiten neben Vaadin den Wechsel vollzogen. Und als wir uns die heutigen Migrationswerkzeuge genauer ansahen, stellte sich heraus, dass auch das Vaadin-Problem lösbar ist: Mit einem Gradle-Plugin, das auf dem Apache Tomcat Migration Tool für Jakarta EE aufbaut, konnten wir die Vaadin-Abhängigkeiten automatisch in den neuen Namespace konvertieren. Damit läuft die Workplace ohne Neuentwicklung auch auf modernen Servlet-Containern. Der Rest der Migration war danach eine überschaubare Arbeit. Tatsächlich liegt der größte Teil bereits hinter uns: Die opencms-core-Quellen sind konvertiert, die aktive Entwicklung läuft inzwischen auf Jakarta-Basis, und alles funktioniert wie erwartet.

Der Namespace-Wechsel auf einen Blick

Tomcat 11 basiert auf Jakarta EE 11. Die für OpenCms relevante Änderung kam schon früher, in Jakarta EE 9: die Namespace-Migration. Code, der bisher Pakete wie diese verwendete:

javax.servlet.*

muss nun diese verwenden:

jakarta.servlet.*

Das ist mehr als eine einfache Umbenennung. Eine Webanwendung muss in dem Namespace geschrieben sein, den der Servlet-Container erwartet. Dasselbe OpenCms-Artefakt kann daher nicht unverändert auf Tomcat 9 und zugleich auf Tomcat 10 oder 11 laufen. Jetty 12 verwischt diese Grenze mit seinem EE-8-Kompatibilitäts-Layer und genau das hat es uns in den letzten Releases erlaubt, das javax-basierte OpenCms auf einer modernen Laufzeitumgebung zu betreiben. Dieser Layer ist aber eine Brücke für bestehende Anwendungen, kein Ziel für neue Entwicklung.

Ein Quellcode, zwei Varianten

Um die Umstellung für bestehende Installationen einfach zu machen, wird OpenCms 22 in zwei Varianten erscheinen:

  • eine Jakarta-Variante für Umgebungen auf Basis von Tomcat 10 / 11
  • eine Legacy-javax-Variante für bestehende Tomcat-9-Umgebungen

Beide Varianten stammen aus einer Codebasis. Im opencms-core-Repository haben wir die Quellen in den neuen Namespace konvertiert und das Ergebnis zum neuen main-Branch gemacht. Die gesamte aktive Entwicklung findet damit auf Jakarta statt, die Vaadin-Abhängigkeiten sind bereits in den neuen Namespace transformiert. Für ein Release wird der main-Branch über den alten master-Branch kopiert und zurückkonvertiert; von dort wird die Tomcat-9-Variante kompiliert. Die ursprüngliche Vaadin-Abhängigkeit funktioniert für diesen Build unverändert und muss nicht transformiert werden.

Was ändert sich für Entwickler?

Für viele OpenCms-Projekte ändert sich zunächst wenig. Die wichtigste Frage ist, auf welchem Servlet-Container ein Projekt laufen soll.

Projekte, die mit den Standardfunktionen von OpenCms arbeiten, wählen einfach die Variante, die zu ihrer Laufzeitumgebung passt. Eigene Module, die direkt auf Servlet-APIs zugreifen, brauchen beim Umstieg auf die Jakarta-Variante eventuell kleine Anpassungen, meist nur eine Änderung der Imports von javax.servlet auf jakarta.servlet.

Der Wechsel bringt auch handfeste Vorteile mit sich. Die Jakarta-Plattform hat sich weiterentwickelt und bietet unter anderem:

  • Eine aufgeräumte Servlet-API. Servlet 6.x verzichtet auf lange veraltete APIs und ergänzt praktische Details wie die direkte Unterstützung von SameSite-Cookies.
  • Modernes JSP / EL. Die Expression Language unterstützt inzwischen neuere Java-Konstrukte wie Records.
  • Kompatibilität mit dem Ökosystem. In der Praxis der wichtigste Punkt: Aktuelle Java-Web-Bibliotheken erscheinen nur noch für Jakarta, eigene Module können damit endlich aktuelle Abhängigkeiten nutzen.

Für Neuentwicklungen ist Jakarta EE die empfohlene Richtung.

Der Upgrade-Pfad

OpenCms 22 gibt Projekten Zeit, Schritt für Schritt umzustellen:

  • Führen Sie bestehende Installationen bei Bedarf weiterhin mit der Legacy-Variante aus.
  • Testen Sie eigene Module und Integrationen mit der Jakarta-Variante.
  • Wechseln Sie zu Tomcat 11, sobald das Projekt bereit ist.

Die nächste Hauptversion, OpenCms 23 (April 2027), schließt die Umstellung ab und wird ausschließlich auf Jakarta basieren.

Ein Blick in die Zukunft

Jetty ist nach wie vor eine hervorragende Laufzeitumgebung für OpenCms, und wir schätzen sie weiterhin sehr. Viele Projekte und Hosting-Umgebungen bevorzugen jedoch Tomcat, und mit der Unterstützung von Jakarta EE 11 ist OpenCms auf dem Stand der aktuellen Java-Webplattform.

Durch die Umstellung des Quellcodes auf Jakarta und eine Kompatibilitätsvariante für eine Übergangsversion bietet OpenCms 22 jedem Projekt einen klaren technischen Weg nach vorn, ohne dass jemand sofort migrieren muss.