Java 8 und Java 11 im Unternehmen: Wie lange ist der Betrieb noch vertretbar?
Java 8 end of life ist für viele Unternehmen eine abstrakte Meldung aus der IT-Abteilung. Die Anwendung läuft. Niemand hat sich beschwert. Also bleibt alles, wie es ist.
Das Problem zeigt sich erst später. Java 8 bekommt seit Jahren keine kostenlosen Sicherheitsupdates mehr von Oracle. Java 11 steht kurz davor, denselben Weg zu gehen. Wer beide Versionen betreibt, sollte wissen, wo der Betrieb heute steht. Und wann er riskant wird.
Dieser Artikel erklärt, was Java 8 end of life und Java 11 end of support bedeuten. Er zeigt die Risiken eines längeren Weiterbetriebs. Und er beschreibt, wie der Umstieg auf Java 21 praktisch gelingt, Schritt für Schritt.
Was bedeutet End of Life bei Java 8 und Java 11 konkret?
Java 8 erschien im März 2014, Java 11 folgte im September 2018. Beide gelten als LTS-Version, kurz für Long Term Support. Das heißt: eine besonders lange Pflegezeit, verglichen mit den Zwischenversionen.
Oracle hat die reguläre Premier-Support-Phase für Java 8 im März 2022 beendet. Für Java 11 endete sie im September 2023. Das ist der Kern von Java 8 end of life. Seitdem gibt es nur noch unter zwei Bedingungen Updates. Erstens über einen kostenpflichtigen Extended-Support-Vertrag mit Oracle. Zweitens über den Wechsel auf eine freie OpenJDK-Distribution.
Eclipse Temurin und Amazon Corretto sind zwei bekannte Beispiele für solche Distributionen. Beide basieren auf OpenJDK, der offenen Basis, auf der auch Oracles eigenes Produkt aufsetzt. Sie liefern weiterhin kostenlose Sicherheitsupdates für Java 8 und Java 11. Eine Herstellergarantie wie bei einem Oracle-Vertrag gibt es dabei allerdings nicht.
Oracles Extended Support läuft für Java 8 bis Dezember 2030. Für Java 11 reicht er bis Januar 2032. Das klingt lang. Es gilt aber nur mit einem laufenden, bezahlten Vertrag. Ohne diesen Vertrag und ohne Umstieg auf eine freie Distribution gilt das nicht. Ihre Anwendung bekommt dann schlicht keine Sicherheitsupdates mehr.
Welche Risiken entstehen, wenn Sie einfach weiterlaufen lassen?
Sicherheitslücken ohne Patches
Jede Software hat Fehler. Bei aktiv gepflegten Java-Versionen werden neu entdeckte Sicherheitslücken regelmäßig geschlossen. Ohne Support bleibt eine Lücke offen, sobald sie öffentlich bekannt wird. Wer automatisiert nach verwundbaren Systemen sucht, findet solche offenen Lücken zuverlässig.
Ein Beispiel aus der Praxis: Ein mittelständischer Zulieferer betreibt seine interne Auftragsverwaltung seit 2016 auf Java 8. Die Anwendung läuft stabil. Niemand hat sie seitdem angefasst. Dann wird ein Pentest beauftragt, eine kontrollierte Prüfung auf Sicherheitslücken. Der Prüfer findet mehrere seit Jahren bekannte, ungepatchte Lücken in den eingesetzten Bibliotheken. Für eine aktuell gepflegte Java-Version wären diese längst geschlossen worden.
Haftung und Datenschutz
Die DSGVO verlangt einen Schutz nach dem Stand der Technik. Eine Java-Version ohne Sicherheitsupdates erfüllt dieses Kriterium nicht. Bei einem Vorfall fragt eine Aufsichtsbehörde genau nach dem Patch-Stand. Eine überzeugende Antwort gibt es dann nicht.
Abhängigkeiten, die nicht mehr mitziehen
Bibliotheken und Frameworks entwickeln sich weiter. Viele aktuelle Versionen setzen mindestens Java 11 oder Java 17 voraus. Wer auf Java 8 stehen bleibt, kann manche Updates irgendwann nicht mehr einspielen. Das betrifft zum Beispiel aktuelle Spring-Framework-Versionen. Spring Boot 3 setzt Java 17 voraus und bricht mit älteren Konfigurationen.
Was tun: der Weg zu Java 21
Ein Java-Upgrade ist selten ein einfacher Versionswechsel. Trotzdem lässt es sich strukturiert angehen.
Schritt 1: Bestandsaufnahme
Welche Java-Version läuft wo? Welche Bibliotheken und internen Tools hängen daran? Bei älteren Java-EE-Anwendungen kommen oft zusätzliche Abhängigkeiten zum veralteten Anwendungsserver hinzu. Unser Artikel über Java EE Anwendungen warten zeigt, was sich dort über die Jahre angesammelt hat.
Schritt 2: Kompatibilitätsprüfung
Java 9 hat mit dem Modulsystem einige interne APIs entfernt. Wer seinen Code dagegen prüft, findet frühzeitig Stellen, die angepasst werden müssen. Automatisierte Werkzeuge helfen bei diesem Schritt.
Schritt 3: Testumgebung und stufenweises Vorgehen
Ein Upgrade gehört nie direkt in die Produktion. Eine Testumgebung mit der neuen Java-Version zeigt, was wirklich funktioniert. Bei größeren Systemen lohnt sich ein stufenweises Vorgehen. Zuerst unkritische Module, dann die Kernanwendung.
Schritt 4: Go-Live und Beobachtung
Nach dem Umstieg braucht es aufmerksames Monitoring. Fehlerprotokolle zeigen schnell, ob etwas übersehen wurde. Die ersten Wochen nach einem Upgrade verdienen besondere Aufmerksamkeit.
Manche Unternehmen wollen mehr als nur die Java-Version heben. Sie planen die komplette Altarchitektur abzulösen. Einen Überblick über die gängigen Wege dafür bietet unser Artikel Java EE ablösen.
Welche Java-Version ist 2026 die richtige Wahl?
Java 21 ist seit September 2023 die aktuelle LTS-Version. Der Premier Support läuft bis September 2028. Seit 2025 gibt es mit Java 25 bereits die nächste LTS-Version.
Für die meisten Unternehmen ist der Umstieg auf Java 21 der pragmatische Zielpunkt. Die Version ist ausgereift und breit unterstützt. Sie bringt zudem spürbare Verbesserungen gegenüber Java 8. Dazu zählen schnellere Startzeiten und ein moderner Garbage Collector, der Speicher automatisch aufräumt. Virtuelle Threads erlauben außerdem eine deutlich einfachere Verarbeitung vieler gleichzeitiger Anfragen. Wer ohnehin neu baut, kann direkt auf Java 25 planen.
Was kostet der Umstieg und wie lange dauert er?
Das hängt stark vom Ausgangspunkt ab. Eine gepflegte Spring-Boot-Anwendung auf Java 11 mit Tests lässt sich oft schnell heben. Oft reichen dafür wenige Tage. Eine gewachsene Java-EE-Anwendung aus den 2000er Jahren braucht mehr Zeit. Ohne Tests und mit proprietären Bibliotheken kann das mehrere Wochen dauern.
Den Aufwand bestimmen vor allem drei Dinge. Erstens die Codequalität. Zweitens das Alter der Abhängigkeiten. Drittens die Frage, ob nur die Java-Version oder gleich die ganze Architektur erneuert wird. Die Kosten reichen von wenigen Tausend Euro für ein überschaubares System. Für eine komplexe, gewachsene Anwendung kann ein fünfstelliger Betrag fällig werden.
Eine seriöse Aufwandsschätzung braucht einen Blick in Ihr konkretes System. Pauschale Zahlen helfen an dieser Stelle wenig.
Fazit: Handeln, bevor der Druck von außen kommt
Java 8 end of life und das nahende Java 11 end of support sind kein Grund für Panik. Sie sind ein Grund, jetzt zu planen. Statt später gezwungen zu reagieren.
Die meisten Unternehmen, die uns ansprechen, wissen bereits, dass Handlungsbedarf besteht. Sie haben es nur aufgeschoben, weil das Tagesgeschäft wichtiger wirkte. Das ist menschlich. Nur wartet das Problem nicht auf einen günstigen Zeitpunkt.
Die laufende Software-Wartung für Java-, PHP- und andere Altsysteme übernehmen wir, inklusive Sicherheits-Monitoring. Für einen strukturierten Umstieg auf Java 21 brauchen Sie aber zunächst eine ehrliche Einschätzung Ihres Systems.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
