Upgrade von Java 11 auf Java 21

Prev Next

Release 26.2 ist das erste Release der Lobster Data Platform, das OpenJDK 21 unterstützt, und damit das Release, mit dem Sie den Wechsel vollziehen können. OpenJDK 11 wird in 26.2 übergangsweise weiterhin unterstützt, OpenJDK 21 ist die empfohlene Laufzeit-Umgebung. Sowohl viele unserer Kunden als auch wir verwenden dieses JDK: Adoptium (Eclipse Temurin®), JDK 21-LTS.

Was sich ändert

Im Folgenden finden Sie eine Zusammenfassung der Änderungen, die mit Java 21 eingeführt wurden oder bereits mit Java 17 in Kraft traten. Es ist dabei zu beachten, dass nicht alle diese Änderungen für Sie und die Lobster Data Platform relevant sein werden.

Zeichenkodierung

Die Standard-Kodierung ist jetzt UTF-8, auch unter Windows, wo bisher Cp1252 verwendet wurde. Anwendungen, die Dateien ohne explizite Kodierung lesen oder schreiben, können sich anders verhalten. Prüfen Sie insbesondere Logdateien, CSV-Exporte und Datenbankimporte.

Rückfallmöglichkeit: -Dfile.encoding=WINDOWS-1252 als JVM-Parameter

Zugriff auf interne APIs

Die Option --illegal-access existiert nicht mehr. Frameworks oder Libraries, die auf interne Java-APIs zugreifen, brechen ab. Sie können das durch gezielte --add-opens-Einträge in Ihren Startskripten nachbilden.

TLS-Verbindungen

TLS 1.0 und 1.1 sind standardmäßig deaktiviert. Verbindungen zu Altsystemen (z. B. Legacy-Datenbanken, ältere LDAP-Server) schlagen fehl.

Sicherheitshinweis

Reaktivierung in conf/security/java.security unter jdk.tls.disabledAlgorithms – nur als Übergangslösung.

Siehe TLS-Java-Änderungen beachten.

Tool

Nutzen

jpackage

Erzeugt native Installer (.msi, .deb, .rpm)

jwebserver

Einfacher HTTP-Server für schnelle Tests

Empfohlene Installationsweise: JDK entpacken, nicht installieren

Wir empfehlen, das OpenJDK nicht über den Windows-Installer oder den Paketmanager Ihres Betriebssystems zu installieren, sondern das ZIP- bzw. Tarball-Archiv (z. B. von Adoptium) in ein eigenes Verzeichnis zu entpacken. Gründe:

  • Entkoppelt von automatischen OS-Updates – Ein Betriebs-System- oder Paket-Manager-Update kann die JDK-Version nicht ohne Ihr Wissen ändern.

  • Kontrollierte Erneuerung – Jeder JDK-Wechsel wird bewusst durchgeführt. Sie können ihn vorher in Staging prüfen.

  • Schneller Rollback – Funktioniert eine neue Java-Version nicht, wechseln Sie in den Lobster-Start-Skripten oder in platform.json den Pfad zurück auf das zuvor entpackte JDK und starten neu.

Die Auswahl der aktiven JVM erfolgt ausschließlich über die Lobster-Start-Skripte bzw. die Wrapper-Konfiguration (JAVA_HOME in hubenv.bat / hub.sh oder der JDK-Pfad in platform.json ab 26.2). Eine systemweite Java-Registrierung ist für den Betrieb der Lobster Data Platform nicht erforderlich.

Schritt für Schritt: Upgrade durchführen

  1. JDK 21 entpacken: Entpacken Sie das JDK-21-Archiv in ein eigenes Verzeichnis (z. B. C:\java\jdk-21.x.x bzw. /opt/java/jdk-21.x.x) parallel zum bestehenden JDK 11. Das bisherige JDK 11 bleibt als Rollback-Option erhalten.

  2. JAVA_HOME und PATH auf das neue Verzeichnis umstellen.

  3. Anwendung im Testbetrieb starten und auf Encoding-Probleme und TLS-Fehler achten.

  4. JDK 11 erst deinstallieren, wenn alles stabil läuft.

SecurityManager unter Java 21

Beim Start der Lobster Data Platform unter Java 21 erscheint folgende Meldung in logs/wrapper.log:

*** INFO: SecurityManager could not be installed. See documentation for more details ***

Der Security-Manager von Java wurde von Oracle als veraltet eingestuft. Er steht unter Java 21 nicht mehr zur Verfügung. Die JVM lehnt den Installations-Aufruf ab. Die Plattform startet und läuft wie gewohnt.

Was sich durch den Wegfall des SecurityManagers ändert

Innerhalb der Lobster Data Platform übernahm der SecurityManager zwei Aufgaben:

  • System.exit()-Interception, die verhinderte, dass Libraries die JVM abrupt beenden.

  • Runtime.exec()-Interception, die verhinderte, dass Libraries externe Prozesse starten.

Beide Schutzfunktionen sind unter Java 21 nicht mehr aktiv.

Wie Sicherheit jetzt gewährleistet wird

Diese Schutzfunktionen liegen jetzt in der Verantwortung des Betriebssystems oder der Container-Laufzeit. Verwenden Sie OS-seitige Prozess-Kontrollen oder Container-Sicherheits-Richtlinien, um den Prozessabbruch und das Starten externer Prozesse einzuschränken. Beispiele hierfür sind Linux-seccomp-Profile oder Kubernetes-Security-Kontexte.

Keine anderen Sicherheits-Mechanismen der Plattform stützten sich auf den SecurityManager. Die Sandbox-Funktionen, die er ursprünglich bot, waren nicht im Einsatz.

Verwandte Artikel