Ende des Supportzyklus für OpenJDK 17: Wichtige Termine, Ihre Optionen und Support

Wichtigste Erkenntnisse

• Für OpenJDK 17 gibt es kein einheitliches End-of-Life-Datum, und der Support durch die Anbieter erstreckt sich über den Zeitraum von September 2026 bis mindestens Oktober 2029.
• Sobald der Support endet, werden keine CVE-Patches mehr bereitgestellt, und es wird schwieriger, Konformitätsprüfungen zu bestehen und Versicherungsverträge zu verlängern.
• Teams, die noch nicht bereit für die Migration sind, können weiterhin CVE-Patches über den erweiterten Support von Drittanbietern erhalten, ohne ihre Laufzeitumgebung oder ihren Code ändern zu müssen.

Wenn Ihre Produktions-Workloads noch auf OpenJDK 17 laufen, sind Sie in guter Gesellschaft. Java 17 war aus gutem Grund die „sichere“ LTS-Wahl – stabil, gut unterstützt und weitgehend kompatibel. Das Problem ist, dass „unterstützt“ mittlerweile je nach der von Ihnen verwendeten Distribution etwas anderes bedeutet und die entsprechenden Zeiträume nicht einheitlich sind.

In diesem Artikel geht es darum, was das Ende des Supports (EOL) für OpenJDK 17 in der Praxis tatsächlich bedeutet, welche konkreten Termine für die gängigsten Builds gelten, warum die Migration schwieriger ist, als es in der Dokumentation den Anschein hat, und welche Optionen Ihnen tatsächlich zur Verfügung stehen, wenn die Frist näher rückt, als die Codebasis dafür bereit ist.

Überblick über den Lebenszyklus und den Support von OpenJDK

OpenJDK ist die von Oracle betreute Open-Source-Referenzimplementierung von Java SE. Es ist jedoch nicht dasselbe wie das „Oracle JDK“ – und genau diese Unterscheidung macht die EOL-Planung so verwirrend.

Die OpenJDK-Community im Upstream-Bereich unterstützt eine Hauptversion etwa sechs Monate lang, bis die nächste Feature-Version veröffentlicht wird. Der Langzeit-Support (LTS) ist eine Angelegenheit des Downstream-Bereichs und wird von Anbietern übernommen, die ihre eigenen Builds bündeln und mit Patches versehen. Seit Java auf einen sechsmonatigen Release-Rhythmus umgestellt hat, erhalten nur bestimmte Versionen die LTS-Kennzeichnung. Java 17 ist eine davon. Java 21 und Java 25 sind neuere LTS-Versionen.

Hier ist der aktuelle Stand der LTS-Versionen:

Die Einführung hinkt diesen Terminen jedoch noch deutlich hinterher. Der „2025 Java Developer Productivity Report“ von JRebel ergab, dass 61 % der Befragten noch mit Java 17 arbeiten. In der gesamten Stichprobe gaben 72 % an, Oracle-Distributionen zu nutzen, für die der kostenlose öffentliche Support bereits ausgelaufen ist, darunter 35 % mit Java 8 und 32 % mit Java 11. Es ist sehr wahrscheinlich, dass Ihr Team neben der Version, auf die Sie migrieren möchten, noch mindestens eine EOL-Version verwaltet.

Wichtige Termine für OpenJDK 17

Das Wichtigste, was man verstehen muss: Es gibt kein einheitliches EOL-Datum für OpenJDK 17. Jede Distribution folgt ihrem eigenen Zeitplan.

Die beiden Termine, die die meisten Teams derzeit im Auge behalten sollten, sind das Auslaufen des Oracle Premier Support im September 2026 und das von Red Hat im Dezember 2027. Wenn Sie Oracle JDK 17 ohne Universal-Abonnement nutzen, wurden die kostenlosen Sicherheitsupdates im September 2024 eingestellt. Für weitere Updates ist ein kostenpflichtiges Oracle Java SE Universal-Abonnement erforderlich.

Eine umfassende Übersicht darüber, wie sich die Oracle- und OpenJDK-Builds hinsichtlich der Lizenz- und Supportbedingungen unterscheiden, finden Sie in unserem Leitfaden „OpenJDK vs. Oracle JDK “.

Java 17 war die LTS-Version, die veröffentlicht wurde, als Oracle die Umstellung auf einen zweijährigen LTS-Rhythmus ankündigte; ab Java 21 verkürzte sich der Abstand zwischen den LTS-Veröffentlichungen von drei auf zwei Jahre. Durch den kürzeren Zyklus sehen sich Unternehmen nun alle zwei statt alle drei Jahre mit einem Upgrade-Druck konfrontiert – doch die Migrationszeitpläne der meisten Teams wurden noch nicht entsprechend angepasst.

Was passiert eigentlich, wenn OpenJDK 17 das Ende seiner Lebensdauer erreicht?

Ihre JVM läuft weiter. Genau das ist der Grund, warum Teams dazu verleitet werden, EOL-Termine zu ignorieren – am ersten Tag geht noch nichts kaputt. Die Anwendung, die gestern noch einwandfrei funktionierte, sieht morgen noch genauso aus. Was sich ändert, ist das, was vorgelagert geschieht. Oder genauer gesagt: das, was nicht mehr geschieht.

Nach Ablauf der Lebensdauer (EOL) bauen sich im Hintergrund drei Risikofaktoren auf.

1. Sicherheitspatches werden eingestellt

Das ist der entscheidende Punkt. Nach dem EOL stellt der Betreuer die Rückportierung von CVE-Korrekturen auf Ihre Version ein. Neu entdeckte Sicherheitslücken in den JVM-Interna, der Standardbibliothek, den TLS-Implementierungen oder den Deserialisierungswegen – keine davon wird in Ihrer Version behoben. Sie werden in Java 21 und 25 behoben. Ihre Version bleibt einfach so, wie sie ist.

Die JVM ist kein kleines Ziel. Java war in den letzten zehn Jahren an einigen der am häufigsten ausgenutzten Schwachstellenkategorien beteiligt, und in jedem vierteljährlichen „Critical Patch Update“-Zyklus tauchen immer wieder neue CVEs auf. Sobald Ihre Version aus dieser Liste gestrichen wird, sammeln sich alle ungepatchten Probleme an, die zwischen dem Ende des Supports (EOL) und dem Zeitpunkt, zu dem Sie die Migration schließlich abschließen, auftreten.

2. Die Einhaltung der Vorschriften wird schwieriger

Die meisten Compliance-Rahmenwerke – PCI DSS, HIPAA, SOC 2, FedRAMP, ISO 27001 – enthalten ausdrückliche oder implizite Anforderungen hinsichtlich des Betriebs unterstützter Software mit aktuellen Patches. Die Prüfer legen diesbezüglich immer größere Wert auf Genauigkeit, und die Aussage „Wir hatten vor, ein Upgrade durchzuführen“ ist in einem Prüfbericht keine zufriedenstellende Antwort.

Wenn Sie eine Java-Version verwenden, deren Lebenszyklus beendet ist, befinden Sie sich in folgender Situation:

• Fehlgeschlagene automatisierte Schwachstellenscans – Nessus, Qualys, Wiz und ähnliche Tools kennzeichnen EOL-Laufzeitumgebungen standardmäßig als problematisch
• In jedem Prüfungszyklus zusätzliche Zeit für die Dokumentation und Begründung von Ausnahmen aufwenden
• Erschwerung bei der Verlängerung von Cyberversicherungen – mehrere große Versicherer fragen mittlerweile direkt nach, ob Software, deren Lebenszyklus abgelaufen ist (EOL), im Produktivbetrieb eingesetzt wird
• Nach einem Vorfall ist es sehr schwierig zu erklären, dass man das Risiko einer Offenlegung der Datenschutzverletzung in Kauf genommen hat, weil „wir wussten, dass dies nicht gerechtfertigt war“.

Realitätscheck: Der Verizon DBIR 2025 ergab, dass die Ausnutzung von Sicherheitslücken als Einstiegsvektor im Vergleich zum Vorjahr um 34 % zugenommen hat und mittlerweile 20 % aller Sicherheitsvorfälle ausmacht. Ungepatchte Laufzeitumgebungen sind genau der Ort, an dem dies geschieht.

3. Der Abbau von Abhängigkeiten ist ein sich nur langsam entwickelndes Problem

Das hier betrifft Teams, die glauben, sie hätten bereits vorausschauend geplant. Selbst wenn Ihre Java-Laufzeitumgebung bei Version 17 bleibt, bleibt der Rest Ihres Stacks nicht mit ihr stehen.

Frameworks stellen die Unterstützung für ältere JDKs ein. Spring Boot veröffentlicht jedes Jahr eine neue Hauptversion und erhöht regelmäßig seine Basisversion. Bibliotheksbetreuer stellen die Tests mit EOL-JVMs ein. Container-Basisimages werden für neuere JDKs neu erstellt. Irgendwann stößt man auf ein Abhängigkeits-Update, bei dem eine transitive Bibliothek eine Funktion benötigt, die erst ab Java 21 verfügbar ist, und das Upgrade, das man zwei Jahre lang aufgeschoben hat, muss plötzlich in diesem Sprint erfolgen – zum ungünstigsten Zeitpunkt überhaupt.

Warum ein Upgrade nicht immer einfach ist

Der Sprung von Java 17 auf 21 oder 25 verläuft tatsächlich reibungsloser als die meisten früheren Umstellungen auf neue Hauptversionen. Das heißt aber nicht, dass er kostengünstig ist. Genau hier geraten Teams oft ins Stocken.

Ihre Abhängigkeiten sind noch nicht alle bereit

Ein Upgrade der Java-Version ist nicht nur ein einfacher Wechsel der JVM. Es betrifft jede Bibliothek, jedes Framework und jedes interne Artefakt, das an eine bestimmte Bytecode-Stufe gebunden ist oder auf interne Komponenten zurückgreift, die sich zwischen den Versionen geändert haben.

Zu den häufigen Unterbrechungen auf der Strecke 17 → 21 gehören:

• Reflection-intensive Bibliotheken, die mit strengeren Kapselungsregeln konfrontiert sind
• Ältere Tools zur Bytecode-Bearbeitung – ASM, einige Byte-Buddy-Versionen, ältere Hibernate-Versionen – erfordern umfassende Aktualisierungen
• Code unter Verwendung von sun.misc.Unsafe auf Warnungen wegen veralteter Funktionen stoßen oder auf APIs, die komplett entfernt wurden
• Build-Tools (Maven Surefire, Gradle, JaCoCo), bei denen Versionserhöhungen synchron erfolgen müssen
• Container-Images und CI-Runner, die parallel aktualisiert werden müssen

Ein Team, das mit einem vier Jahre alten Monolithen arbeitet, wird das meiste davon in der Regel erst dann entdecken, wenn der Upgrade-Zweig in die CI gelangt. Planen Sie dafür Mittel ein.

Ihre Testabdeckung ist wahrscheinlich nicht so gut, wie es sich anfühlt

JVM-Upgrades decken Fehler auf, die von Unit-Tests nicht erkannt werden. Das Verhalten der Garbage Collection ändert sich von Version zu Version. Die Standardeinstellungen verschieben sich. Der JIT-Compiler trifft andere Entscheidungen. Die Behandlung von Ländereinstellungen, Zeitzonen und das Verhalten der Regex-Engine – all dies hat bei früheren Upgrades zu echten Produktionsausfällen geführt.

Wenn Ihre Testsuite keine echten Datenbanken, keine echte E/A und keine realistischen Lastprofile berücksichtigt, wird das Upgrade die CI-Prüfung bestehen, in der Produktion jedoch fehlschlagen. Dies ist der Teil des Migrationsplans, der oft stillschweigend übersprungen wird, und er ist die Ursache für die meisten Nachbesprechungen nach dem Motto: „Wir haben das Upgrade bereits durchgeführt – warum funktioniert dann nichts mehr?“

Der Kalender stimmt nicht mit dem Quellcode überein

Selbst wenn die technische Migration machbar ist, sieht die organisatorische Realität oft anders aus. Die Kapazitäten der Entwickler werden quartalsweise zugewiesen. Das Upgrade konkurriert mit der Entwicklung neuer Funktionen, Sicherheitsrückständen und dem jeweiligen Vorfall, der in dieser Woche die Aufmerksamkeit des Teams auf sich zieht. Eine auf dem Papier mit drei Monaten veranschlagte Migration dauert in der Praxis neun Monate, weil niemand ununterbrochen Zeit dafür aufbringen kann.

Aus der Praxis: Ein typisches Szenario: Ein Team plant das Upgrade von Java 17 auf 21 für das erste Quartal, stößt auf einen Konflikt mit einer Hauptversion von Spring Boot, verschiebt das Projekt auf das zweite Quartal, wird in die Vorbereitungen für ein SOC-2-Audit hineingezogen, und das Ganze rutscht schließlich ins vierte Quartal. Bis dahin ist Java 25 verfügbar, und das Ziel verschiebt sich erneut. Die Teams, die ihre Zeitfenster tatsächlich einhalten, behandeln EOL-Termine als feste Projektmeilensteine mit namentlich benannten Verantwortlichen – und nicht als Backlog-Elemente, um die sie sich irgendwann einmal kümmern werden.

Ihre Optionen nach dem Ende des Supportzeitraums (EOL) für OpenJDK 17

Es gibt keine allgemeingültige Antwort. Der beste Weg hängt von Ihren technischen Kapazitäten ab, davon, wie fest Ihr Technologie-Stack festgelegt ist, und davon, wie streng Ihre Compliance-Anforderungen sind. Hier sind die realistischen Optionen.

Option 1: Erweiterter Support durch Drittanbieter für OpenJDK 17

Falls ein Upgrade innerhalb Ihres aktuellen Zeitplans nicht realistisch ist, ist ein erweiterter Lebenszyklus-Support durch Drittanbieter der sauberste Weg, um weiterhin CVE-Patches zu erhalten, ohne Ihre Laufzeitumgebung zu verändern oder Ihren Code umzuschreiben. Dieser Ansatz eignet sich besonders gut für Teams, die OpenJDK 17 auf verschiedenen Linux-Distributionen – RHEL, AlmaLinux, Rocky, Ubuntu, Debian – einsetzen, bei denen die Lebenszyklen des Betriebssystem-Supports und des JDK-Supports nicht nahtlos ineinandergreifen.

Der „Endless Lifecycle Support“ von TuxCare für OpenJDK bietet fortlaufende Sicherheitspatches für OpenJDK-Versionen wie 17, 11, 8 und 7 – und deckt damit die meisten wichtigen Linux-Distributionen für Unternehmen ab. Der Ansatz ist einfach: Sie behalten Ihre bestehenden Builds bei, erhalten weiterhin Patches, sobald neue CVEs bekannt werden, und verschaffen sich so Zeit, um eine fundierte Migration zu planen, anstatt diese überstürzt durchzuführen. Er wurde speziell für Teams entwickelt, die aufgrund regulatorischer Auflagen keine ungepatchten Laufzeitumgebungen betreiben dürfen, aber auch nicht alles stehen und liegen lassen können, um noch in diesem Quartal ein umfangreiches Versions-Upgrade durchzuführen.

Option 2: Upgrade auf Java 21 oder Java 25

Die langfristig richtige Lösung für die meisten Teams. Sofern Sie über die entsprechenden technischen Ressourcen verfügen, bietet Ihnen ein Upgrade auf eine aktuelle LTS-Version jahrelangen kostenlosen öffentlichen Support, deutliche Leistungsverbesserungen und fortlaufende Kompatibilität mit dem sich weiterentwickelnden Ökosystem. Gemäß der Support-Roadmap von Oracle erhält Java 21 bis September 2028 „Premier Support“ und Java 25 bis September 2030 – sollten Sie jedoch Corretto, Temurin oder eine andere Version verwenden, überprüfen Sie bitte den spezifischen Zeitplan Ihres Anbieters.

Dies ist die richtige Entscheidung, wenn:

• Ihr Code ist klein oder so gut getestet, dass die Migration innerhalb eines Quartals möglich ist.
• Ihre CI-Abdeckung erfasst tatsächlich Verhaltensänderungen und nicht nur Kompilierungsfehler.
• Ihre wichtigsten Abhängigkeiten unterstützen bereits Java 21 und höher
• Sie können einen zielgerichteten Entwicklungssprint gestalten, ohne dass dieser in drei verschiedene Richtungen gezogen wird

Option 3: Wechseln Sie zu einer anderen OpenJDK-Distribution

Falls Sie Oracle JDK 17 verwenden und die Lizenzumstellung im September 2024 Sie unvorbereitet getroffen hat, müssen Sie nicht sofort auf Java 21 umsteigen, um das Lizenzproblem zu umgehen. Sie können zu Eclipse Temurin, Amazon Corretto oder der Microsoft-Build-Version von OpenJDK wechseln, ohne Ihren Java-Code anzupassen – alle diese Varianten sind TCK-zertifiziert und verhalten sich bei den allermeisten Workloads identisch.

Die Abkehr vom Oracle JDK ist bereits seit einigen Jahren im Gange – Daten von New Relic zeigen, dass der Marktanteil von Oracle am JDK-Markt von 75 % im Jahr 2020 auf 21 % im Jahr 2024 gesunken ist, während Eclipse Adoptium im Jahresvergleich um 50 % zulegte. Die meisten Teams, die umgestiegen sind, mussten dafür keine einzige Zeile Java-Code ändern.

Ein paar Dinge, die Sie vor dem Wechsel überprüfen sollten:

• Bitte überprüfen Sie das EOL-Datum der neuen Distribution für Java 17 – diese variieren zwischen einem und drei Jahren.
• Prüfen Sie, ob herstellerspezifische JVM-Flags oder -Erweiterungen vorhanden sind (selten, aber eine Überprüfung lohnt sich)
• Aktualisieren Sie das Provisioning, die Container-Images und die CI, damit diese Daten aus der neuen Quelle beziehen.
• Dokumentieren Sie die Änderung für die Compliance-Unterlagen

Achtung: Der Wechsel der Distribution ist ein taktischer Schachzug, keine langfristige Lösung. Corretto 17 und die Microsoft-Builds bieten in einigen Fällen eine Unterstützung, die über den Zeitrahmen von Red Hat hinausgeht, doch alle diese Unterstützungen enden irgendwann. Nutzen Sie den Wechsel, um sich 12 bis 24 Monate Zeit zu verschaffen – nicht als Grund, die eigentliche Migration nicht mehr zu planen.

Option 4: Das Risiko (bewusst) in Kauf nehmen

Manche Teams treffen diese Entscheidung tatsächlich, und in bestimmten Kontexten ist sie vertretbar. Interne Tools, isolierte Umgebungen, Wegwerf-Workloads – nicht alles rechtfertigt den technischen Aufwand für eine gepatchte Laufzeitumgebung.

Treffen Sie die Entscheidung bewusst, dokumentieren Sie sie und segmentieren Sie das Risiko so, dass keine ungepatchte JVM auf einem öffentlich zugänglichen Endpunkt verbleibt. Kombinieren Sie dies mit einem automatisierten Patch-Management-Ansatz für den Rest Ihres Stacks, damit die nicht mehr unterstützte Komponente nicht automatisch zum schwächsten Glied wird. Machen Sie sich außerdem den Unterschied zwischen Patch-Management und Schwachstellenmanagement klar – es handelt sich nicht um dieselbe Disziplin, und gerade durch deren Vermischung werden nicht mehr unterstützte Komponenten überhaupt erst übersehen.

Sicherheit für OpenJDK nach Ablauf der Supportfrist mit TuxCare

Die unangenehme Wahrheit bezüglich des EOL von Java ist, dass gerade die Tatsache, dass „die Laufzeitumgebung immer noch funktioniert“, dazu führt, dass man das Thema leicht vernachlässigt. Es werden keine Patches mehr bereitgestellt, Abhängigkeiten veralten, Audit-Befunde häufen sich – und dann taucht eines Tages eine CVE mit einem funktionierenden Exploit auf, und Ihre Version steht nicht auf der Patch-Liste.

Wenn Ihr Team OpenJDK 17 einsetzt und der auf dem Papier festgelegte Zeitplan für die Migration nicht mit der Realität übereinstimmt, ist das keine ungewöhnliche Situation. Das Upgrade ist langfristig die richtige Lösung. Wenn Sie jedoch noch ein oder zwei Quartale davon entfernt sind, es ordnungsgemäß durchführen zu können, stellt der Betrieb ohne Patches in der Zwischenzeit ein echtes Risiko dar.

Der „Endless Lifecycle Support“ von TuxCare für OpenJDK ist genau auf diesen Zeitraum zugeschnitten – gleiche Builds, gleiche Arbeitsabläufe, CVE-Patches, die nicht verfallen, wenn der Support-Kalender des Upstream-Anbieters dies vorsieht. Er deckt die OpenJDK-Versionen 7, 8, 11 und 17 auf Enterprise-Linux- und Debian-basierten Systemen ab, solange Ihr Unternehmen diese Laufzeit benötigt. Informieren Sie sich über die Preise oder wenden Sie sich an die Experten von TuxCare, um zu erfahren, wie der Support für Ihre Umgebung aussieht.

Zusammenfassung

Artikel Name

Ende des Supportzyklus für OpenJDK 17: Wichtige Termine, Ihre Optionen und Support

Beschreibung

End-of-Life-Termine für OpenJDK 17, Support-Zeitpläne, Unterschiede zwischen Anbietern und Upgrade-Optionen. Erfahren Sie, was EOL bedeutet und wie Sie sich auf Java 17 vorbereiten können.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers