Welche Java-Version? LTS, Distributionen und Migration

Welche Java-Version? LTS, Distributionen und Migration

Welche Java-Version? LTS, Distributionen und Migration

Artikel-Übersicht

Die Frage nach der richtigen Java-Version wird zweimal im Jahr neu gestellt, weil zweimal im Jahr eine neue Ausgabe erscheint. Wer das System dahinter verstanden hat, muss sie nur einmal beantworten. Dieser Artikel erklärt deshalb zuerst den Freigaberhythmus und was LTS bedeutet, gibt dann eine Empfehlung je Einsatzfall und stellt die Distributionen nebeneinander — mit Lizenz und Unterstützungsdauer, der Übersicht, die kein Anbieter neutral schreiben kann. Danach die JDK-JRE-Frage mit einer Klärung, die viele überrascht, praktische Hinweise zur Verwaltung mehrerer Installationen und die häufigen Fehlerbilder. Zum Schluss der Migrationsteil: was zwischen LTS-Versionen tatsächlich bricht und in welcher Reihenfolge man vorgeht.

Zu den konkreten Versionsnummern: Sie stehen hier mit Stand März 2027. Das System dahinter bleibt gültig, die Zahlen nicht — prüfe sie, bevor du dich festlegst.

Wie Java veröffentlicht wird

Java erscheint halbjährlich im März und September; etwa jede vierte Ausgabe ist eine LTS-Version mit mehrjähriger Unterstützung.

Seit dem Wechsel auf diesen Rhythmus im Jahr 2018 kommt alle sechs Monate eine neue Hauptversion. Die meisten davon werden nur bis zur nächsten Ausgabe mit Aktualisierungen versorgt — sechs Monate. Die LTS-Ausgaben erscheinen seit Java 17 im Zweijahresabstand und werden deutlich länger gepflegt.

Die LTS-Reihe: Java 8, 11, 17, 21, 25 — die nächste ist für September 2027 vorgesehen.

Was daraus für die Praxis folgt:

  • Anwendungen laufen auf einer LTS-Version. Alles andere bedeutet, alle sechs Monate migrieren zu müssen.
  • Die Nicht-LTS-Ausgaben sind trotzdem nützlich — zum Ausprobieren neuer Sprachmittel, nicht für den Produktivbetrieb.
  • Die Unterstützungsdauer je LTS unterscheidet sich je Distribution, teils erheblich. Dazu unten mehr.

Welche Version für welchen Zweck

Einsatzfall Empfehlung Begründung
Neues Projekt die aktuelle LTS längste verbleibende Unterstützung, neueste Sprachmittel
Bestehende Anwendung die aktuelle LTS, schrittweise erreicht jeweils eine LTS-Stufe pro Migration
Bibliothek für Dritte die älteste noch breit genutzte LTS sonst schließt man Nutzer aus
Lernen und Ausbildung die aktuelle LTS Lehrmaterial und Werkzeuge sind darauf abgestimmt
Experimente mit neuen Sprachmitteln die neueste Ausgabe dafür ist sie da

Stand 03/2027.

Die dritte Zeile ist die, die am häufigsten falsch entschieden wird. Wer eine Bibliothek veröffentlicht und sie gegen die neueste LTS übersetzt, schließt alle aus, die noch nicht dort sind — und das ist in Unternehmensumgebungen die Mehrheit. Die Faustregel: eine LTS-Stufe hinter dem, was man selbst für Anwendungen nutzt.

Die Distributionen

Hier liegt die eigentliche Entscheidung, und sie wird selten sauber getroffen. „Java herunterladen" führt zu mindestens sieben verschiedenen Angeboten, die alle dasselbe können und sich in Lizenz und Unterstützungsdauer unterscheiden.

Distribution Anbieter Lizenz Besonderheit
Eclipse Temurin Adoptium (Eclipse Foundation) quelloffen, frei herstellerneutral, breit eingesetzt — die Standardempfehlung
Oracle JDK Oracle eigene Bedingungen, mehrfach geändert direkt vom Sprachhersteller
Oracle OpenJDK Oracle quelloffen nur bis zur nächsten Ausgabe gepflegt
Amazon Corretto Amazon quelloffen, frei lange Unterstützung, auf AWS abgestimmt
Azul Zulu Azul quelloffen, frei; kommerziell erweiterbar sehr breite Plattformabdeckung
BellSoft Liberica BellSoft quelloffen, frei Varianten mit eingebautem JavaFX
Microsoft Build of OpenJDK Microsoft quelloffen, frei auf Azure abgestimmt
Red Hat build of OpenJDK Red Hat quelloffen, frei im RHEL-Abonnement enthalten

Alle bauen auf demselben Quellcode auf. Die Unterschiede liegen in den Bauzielen, der Unterstützungsdauer, den Plattformen und im Lizenzmodell — nicht in der Sprache.

Die Lizenzfrage

Der Punkt, um den die meisten Übersichten herumschreiben.

Die Bedingungen für das Oracle JDK haben sich seit 2019 mehrfach geändert — in beide Richtungen. Zeitweise war die produktive Nutzung kostenpflichtig, danach unter bestimmten Bedingungen wieder frei, und das Abrechnungsmodell für die kommerzielle Unterstützung wurde umgestellt.

Was heute gilt, steht in den aktuellen Bedingungen und nicht in einem Blogartikel — auch nicht in diesem. Der praktische Rat ist deshalb: Wer die Lizenzfrage nicht ohnehin geklärt hat, nimmt Eclipse Temurin. Es ist quelloffen, frei nutzbar, herstellerneutral und in Unternehmensumgebungen etabliert. Damit stellt sich die Frage gar nicht.

Wenn kommerzielle Unterstützung gefordert ist — etwa weil ein Kunde sie verlangt —, bieten Azul, BellSoft, Red Hat und Oracle entsprechende Verträge an. Auch dann gilt: die Bedingungen lesen, nicht die Zusammenfassung.

JDK oder JRE?

Das JDK enthält alles zum Übersetzen und Ausführen, das JRE nur zum Ausführen.

Und die Klarstellung, die viele überrascht: Ein eigenständiges JRE wird seit Java 11 nicht mehr ausgeliefert. An seine Stelle ist ein Werkzeug getreten, mit dem man sich ein zugeschnittenes Laufzeitabbild baut — nur die Module, die die eigene Anwendung braucht.

Für den Alltag heißt das: Man installiert ein JDK. Punkt. Die Vorstellung, für Server ein kleineres JRE zu nehmen, stammt aus der Zeit vor Java 11.

Für Container ist das zugeschnittene Abbild allerdings ein echter Hebel: Statt ein vollständiges JDK von mehreren hundert Megabyte mitzuliefern, baut man ein Abbild mit nur den benötigten Modulen. In Verbindung mit einem mehrstufigen Build wird daraus ein deutlich kleineres Ergebnis — wie mehrstufige Builds funktionieren, steht in Docker Build Context, .dockerignore und Compose.

Welche Version läuft bei mir?

java -version          # was im Pfad liegt
javac -version         # der Übersetzer — kann abweichen!
echo $JAVA_HOME

Die zweite Zeile ist wichtiger, als sie aussieht. Ein häufiger Fehler ist, dass Laufzeit und Übersetzer aus verschiedenen Installationen kommen — dann übersetzt man gegen Version A und führt mit Version B aus, mit Fehlermeldungen, die auf nichts davon hindeuten.

Für mehrere parallele Installationen gibt es Werkzeuge zur Versionsverwaltung, die das Umschalten je Projekt übernehmen. Sie lohnen sich ab der zweiten Version auf demselben Rechner, und die zweite kommt schneller, als man denkt.

Typische Fehlerbilder

„UnsupportedClassVersionError" — die häufigste Meldung. Sie bedeutet: Der Code wurde mit einer neueren Version übersetzt, als die Laufzeit versteht. Prüfen: javac -version gegen java -version.

Der Bauvorgang nutzt ein anderes JDK als die Entwicklungsumgebung. Bauwerkzeuge und IDEs haben eigene Einstellungen, die von JAVA_HOME abweichen können.

„Java Platform SE binary" reagiert nicht. Meist eine Anwendung mit grafischer Oberfläche, die auf etwas wartet — oder eine falsch verknüpfte Dateizuordnung unter Windows.

Das Übersetzungsziel passt nicht zur Laufzeit. Man kann mit einem neuen JDK für eine ältere Zielversion übersetzen. Das ist nützlich für Bibliotheken und eine Fehlerquelle, wenn es unbeabsichtigt geschieht.

Aktualisieren: was Updates bringen

Innerhalb einer Hauptversion erscheinen vierteljährlich Aktualisierungen, überwiegend mit Sicherheitskorrekturen. Sie sind rückwärtskompatibel und sollten zeitnah eingespielt werden.

Für Container heißt das konkret: Ein Abbild mit fest eingefrorener Java-Version wird mit der Zeit zum Sicherheitsproblem. Das Basisabbild gehört regelmäßig neu gebaut — am besten automatisiert, sonst passiert es nicht.

Ein zweiter Punkt, der unterschätzt wird: Eine LTS-Version, die das Ende ihrer Unterstützung erreicht hat, bekommt keine Sicherheitskorrekturen mehr. Wer auf einer solchen Version bleibt, hat kein Wartungsproblem, sondern ein Sicherheitsproblem — und das ist ein anderes Gespräch mit anderen Beteiligten.

Migration zwischen LTS-Versionen

Der Architekturteil. Was tatsächlich bricht:

Entfernte Module. Beim Sprung über Java 11 hinweg fehlen Module, die früher Teil des JDK waren — Teile der XML- und Java-EE-Unterstützung wurden ausgelagert. Sie sind als eigene Abhängigkeiten weiterhin verfügbar, müssen aber ausdrücklich eingebunden werden.

Stärkere Kapselung interner Schnittstellen. Zugriffe auf JDK-Interna, die früher nur eine Warnung erzeugten, führen inzwischen zu Fehlern. Betroffen sind meist nicht die eigenen Anwendungen, sondern ältere Bibliotheken.

Abhängigkeiten, die nicht mitziehen. Der häufigste tatsächliche Grund, warum eine Migration hängen bleibt. Eine einzige nicht mehr gepflegte Bibliothek kann den ganzen Sprung blockieren.

Verhaltensänderungen in der Laufzeitumgebung. Standardwerte der Speicherbereinigung, Zeichensatzvorgaben, Zufallszahlen. Meist unproblematisch, gelegentlich überraschend.

Das Vorgehen

Drei Schritte, in dieser Reihenfolge:

1. Übersetzen. Zuerst nur dafür sorgen, dass der Code mit dem neuen JDK übersetzt — noch ohne neue Sprachmittel, noch mit altem Übersetzungsziel.

2. Laufen lassen. Dann auf der neuen Laufzeitumgebung ausführen und die Tests durchlaufen lassen. Hier zeigen sich Verhaltensänderungen und Bibliotheksprobleme.

3. Sprachmittel übernehmen. Erst danach die neuen Möglichkeiten nutzen. Wer das mit Schritt eins vermischt, kann bei einem Fehler nicht unterscheiden, ob er von der Migration oder von der Umstellung kommt.

Und die wichtigste Regel: Eine LTS-Stufe pro Migration. Der Sprung von 11 auf 25 in einem Zug ist deutlich riskanter als drei Sprünge nacheinander — bei einem Fehler ist der Suchraum viermal so groß.

Das ist derselbe Grundsatz wie beim Umgang mit Altsystemen allgemein: Umzug und Umbau nicht im selben Schritt. Mehr dazu in Legacy-Software modernisieren.

Häufige Fragen

Welche Java-Version ist aktuell? Java erscheint halbjährlich im März und September. Für Produktivbetrieb zählt die aktuelle LTS-Version; die Zwischenausgaben werden nur sechs Monate gepflegt.

Was bedeutet LTS bei Java? Long Term Support — eine Ausgabe, die über mehrere Jahre Sicherheits- und Fehlerkorrekturen erhält. Seit Java 17 erscheint alle zwei Jahre eine.

Welche Distribution soll ich nehmen? Eclipse Temurin, wenn keine besonderen Anforderungen bestehen: quelloffen, frei, herstellerneutral. Wer kommerzielle Unterstützung braucht, wählt einen Anbieter mit entsprechendem Vertrag.

Was ist der Unterschied zwischen JDK und JRE? Das JDK enthält Übersetzer und Werkzeuge, das JRE nur die Laufzeit. Seit Java 11 wird kein eigenständiges JRE mehr ausgeliefert — man installiert ein JDK und baut sich bei Bedarf ein zugeschnittenes Laufzeitabbild.

Gibt es noch Java-Updates? Ja, vierteljährlich für alle unterstützten Versionen, überwiegend mit Sicherheitskorrekturen. Für abgelaufene Versionen nicht mehr.

Wie migriert man auf eine neue LTS-Version? Eine Stufe pro Migration, und in drei Schritten: erst übersetzen, dann laufen lassen, dann neue Sprachmittel übernehmen.

Und wenn es nicht Java sein soll?

Die Versionsfrage stellt sich nur, solange die Sprachfrage entschieden ist. Für neue Dienste lohnt gelegentlich der Blick daneben: Rust, Go und Kotlin lösen jeweils ein anderes Problem, und Kotlin läuft dabei auf derselben Laufzeitumgebung — die Versions- und Distributionsfragen aus diesem Artikel gelten dort unverändert weiter. Die Abgrenzung der drei steht in Rust, Go oder Kotlin?.

Zusammenfassung und praktische Tipps

Die Versionsfrage ist beantwortbar, sobald man das System dahinter kennt. Die wichtigsten Punkte:

  • Halbjährlicher Rhythmus, LTS alle zwei Jahre. Anwendungen laufen auf LTS, alles andere bedeutet Dauermigration.
  • Bibliotheken eine LTS-Stufe zurück — sonst schließt man Nutzer aus.
  • Alle Distributionen bauen auf demselben Quellcode auf. Unterschiede liegen in Lizenz, Unterstützungsdauer und Plattformen.
  • Im Zweifel Eclipse Temurin. Damit stellt sich die Lizenzfrage nicht.
  • Seit Java 11 gibt es kein eigenständiges JRE mehr — man installiert ein JDK.
  • Prüfe javac -version und java -version getrennt. Sie können auseinanderlaufen.
  • Eine LTS-Stufe pro Migration, und übersetzen, laufen lassen und modernisieren als drei getrennte Schritte.

Mein Rat für den Einstieg: Schreib auf, welche Java-Version in eurem Produktivbetrieb läuft, wann ihre Unterstützung endet und welche Distribution es ist. Diese drei Angaben sind erstaunlich oft nicht bekannt — und sie sind die Grundlage jeder weiteren Entscheidung. Wenn dabei herauskommt, dass die Unterstützung in weniger als einem Jahr endet, hast du kein Wartungsthema mehr, sondern ein Sicherheitsthema.

Ressourcen