Es ist mittlerweile schon einige Monate her, dass Java 17 als das aktuelle LTS-Release veröffentlicht wurde. Damit endet auch der offizielle Support für das Vorgänger LTS-Release Java 11. Auch das Spring-Framework hat seine Mindestanforderung mit dem aktuellen Major-Release 6 auf Java 17 angepasst.
Durch Distributionen wie Amazon Corretto oder Apache Adoptium gibt es aktuell noch einen Support für Java 11 und sogar Java 8. Jedoch wird auch dieser perspektivisch auslaufen. Für die Zwischenversionen ist der Support mittlerweile spärlich verfügbar.
Neben dem eigentlichen JDK stellen aber auch die verwendeten Bibliotheken, Frameworks und Laufzeitumgebungen ein potentielles Problem dar: Spring macht es mit dem aktuellen Major-Release vor. Welche JDK-Version wird die nächste Version des eingesetzten Application-Servers mindestens erfordern? Welche JDK-Version wird das nächste Update einer zentralen Bibliothek erfordern?
Dies kann auch bei notwendigen Security-Updates von Bibliotheken, Frameworks und Laufzeitcontainern zu einem ernsten Problem werden.
Aus der Grafik könnte man lesen, dass ein zögerliches Update vermeintlich hilfreich war: Der Support für Java 8 ist mit am längsten verfügbar. Erst Ende 2026 scheint hier Handlungsbedarf zu bestehen. Das ist teilweise länger als bei Java 11.
Der Schein trügt jedoch: Ein Update von Java 8 auf Java 11 ist mit erheblich mehr Problemen verbunden als ein Update von Java 11 auf Java 17. So sind mit Java 11 JAXB und JAX-WS entfallen. Insbesondere JAXB bereitet hier häufig Probleme, da es bereits für einfache XML-Konfigurationen zum Einsatz kommt.
Mit dem Update von Java 11 auf Java 17 kommen weitere Herausforderungen: Insbesondere der Wechsel des Namespace javax auf jakarta dürfte in größeren Anwendungen zu vielen Anpassungen führen.
Eine Anwendung auf Basis von Java 8 oder noch älter erfordert bereits jetzt eine aufwändige Migration. Mit dem neuen zweijährigen Release-Zyklus von LTS-Releases wird sich diese Situation weiter verschärfen.
Was nun?
Bei dem angekündigten Release-Zyklus von einem LTS-Release alle zwei Jahre wird es unerlässlich, auf dem aktuellen Stand zu bleiben. Damit bleibt der Update-Aufwand für jeden individuellen Wechsel von einem zum nächsten LTS-Release überschaubar und das Risiko durch fehlende Security-Updates in eingesetzten Komponenten beherrschbar.
Gegen ein Nicht-LTS-Release für erste Versuche zwischen den LTS-Releases ist nichts einzuwenden. Gegen einen produktiven Einsatz spricht jedoch deren sehr kurze Support-Zeit. Viele Features werden hier als experimentelle Features eingeführt und ändern sich auch durchaus zum nächsten Release, so dass sich diese für einen produktiven Einsatz disqualifizieren – was aber auch nicht vorgesehen ist.
Gerne helfen wird bei Fragestellungen zu einem möglichen Update und der passenden Update-Strategie. Mit unserem Java 17 Update-Seminar vermitteln wir ihren Entwickler:innnen die notwendigen Kenntnisse für das Update.
zurück zur Blogübersicht