Welche Java-Version brauche ich? Übersicht für Server

Java ist auf dem Server selten Selbstzweck. Es steht dort, weil ein Minecraft-Server, ein Tomcat, ein Jenkins oder ein Suchindex es verlangt. Und genau deshalb ist die Frage nie "welches Java ist das beste", sondern "welches Java erwartet diese eine Anwendung, und bekomme ich das auf diesem einen Betriebssystem überhaupt". Dieser Artikel beantwortet beides: mit Support-Zeitplänen, mit einer Verfügbarkeitstabelle, die wir in echten Containern nachgemessen haben, und mit der Praxis des Parallelbetriebs mehrerer Versionen.

Die Kurzfassung: welche Version für welchen Zweck

Wenn Sie keine Zeit haben, ist das hier die Entscheidung:

• Neues Projekt, freie Wahl: Java 21. Es ist die derzeit am breitesten unterstützte LTS-Linie, in Debian 13 und in allen aktuellen Ubuntu-Versionen fertig paketiert, und praktisch jede aktuelle Serversoftware läuft darauf.
• Minecraft 1.20.5 bis 1.21.11: Java 21. Zwingend, kein Spielraum.
• Minecraft 26.1 und neuer: Java 25.
• Ältere Anwendung, die "Java 17" in der Doku stehen hat: nehmen Sie Java 17, nicht "17 oder neuer". Bei Modloadern und Plugin-Systemen ist "neuer" oft nicht wahr.
• Java 8 oder 11: nur noch, wenn eine Altanwendung es erzwingt. Beides gehört auf Ihre Liste der Dinge, die abgelöst werden müssen.
• Java 25: die neueste LTS-Linie, sinnvoll für neue Deployments, aber prüfen Sie vorher, ob Ihr Framework schon offiziell darauf freigegeben ist.

Für die reine Installation haben wir eigene Anleitungen: Java 17 auf Debian installieren und Java 21 auf Debian installieren. Dieser Artikel hier ist die Landkarte darüber.

Was LTS bedeutet und wie lange die Versionen gepflegt werden

Java erscheint alle sechs Monate in einer neuen Hauptversion. Die allermeisten davon sind nach genau sechs Monaten tot: Java 22, 23, 24, 26 bekommen kein Sicherheitsupdate mehr, sobald die nächste Version da ist. Auf einem Server wollen Sie die nicht haben.

Interessant sind ausschließlich die LTS-Versionen (Long Term Support). Sie erscheinen seit 2021 alle zwei Jahre: 8, 11, 17, 21, 25, und als nächstes ist Java 29 für September 2027 geplant. Nur diese Linien bekommen über Jahre hinweg vierteljährliche Sicherheitsupdates.

Wichtig ist die Unterscheidung zwischen Oracle und den freien Builds. Für Serverbetrieb greifen Sie in aller Regel zu OpenJDK aus dem Distributionspaket oder zu Eclipse Temurin. Beide sind kostenfrei nutzbar, und die Pflege läuft dort teilweise deutlich länger als bei Oracles kostenloser Lizenz.

Die Zeile für Java 17 überrascht viele: nur noch bis Oktober 2027. Java 17 fühlt sich neu an, ist aber bereits die vorletzte LTS-Generation. Wer heute ein System aufsetzt, das drei Jahre laufen soll, plant besser gleich mit 21 oder 25.

Welche Java-Version Ihre Distribution im eigenen Repository hat

Hier scheitern die meisten Anleitungen im Netz: sie schreiben "apt install openjdk-17-jre-headless" und gehen davon aus, dass das überall klappt. Tut es nicht. Wir haben die Paketlage am 27.07.2026 in frischen Containern nachgemessen.

Lesen Sie die Debian-Spalten zweimal. Debian 12 kennt ausschließlich Java 17. Debian 13 kennt Java 17 nicht mehr, dafür 21 und 25. Es gibt in den offiziellen Debian-Quellen also keine einzige Version, die auf beiden Releases vorhanden ist. Wer ein Deployment-Skript schreibt, das auf bookworm und trixie laufen soll, kann sich nicht auf ein Paket verlassen.

Ubuntu ist in dieser Hinsicht angenehmer: dort liegen alle fünf LTS-Linien nebeneinander im Repository, auf 22.04 genauso wie auf 24.04. Wenn Sie ein System brauchen, auf dem eine Altanwendung mit Java 8 und ein moderner Dienst mit Java 21 gleichzeitig laufen, ist Ubuntu die Abkürzung.

Prüfen Sie im Zweifel selbst, statt zu raten:

apt update
apt-cache policy openjdk-21-jre-headless
apt-cache search openjdk-

Steht bei "Kandidat" beziehungsweise "Candidate" ein (none), gibt es das Paket auf dieser Distribution nicht. Auf der Red-Hat-Familie (AlmaLinux, Rocky, RHEL, Oracle Linux) heißen die Pakete anders, dort listen Sie so:

dnf list java-\*-openjdk-headless
dnf install -y java-21-openjdk-headless

Nehmen Sie für die Übersicht dnf list und nicht dnf list available. Letzteres blendet bereits installierte Pakete aus, nach dem Installieren von Java 21 taucht Java 21 in der Liste also nicht mehr auf, und man sucht an der falschen Stelle. Die Lage in der Red-Hat-Familie, ebenfalls in frischen Containern nachgemessen:

AlmaLinux 10 hat also denselben Schnitt gemacht wie Debian 13 und alles unterhalb von 21 fallengelassen. Ein dnf install java-17-openjdk-headless endet dort mit No match for argument.

headless oder nicht, JRE oder JDK

Auf einem Server nehmen Sie immer die -headless-Variante. Sie verzichtet auf die grafischen Bibliotheken und zieht dadurch keine X11-Abhängigkeiten nach, was auf einem Rootserver dutzende überflüssige Pakete spart. Und -jre-headless reicht, solange Sie nur fertige JAR-Dateien ausführen. Erst wenn Sie selbst kompilieren oder ein Tool javac aufruft, brauchen Sie openjdk-21-jdk-headless.

Auf der Red-Hat-Familie lohnt an dieser Stelle ein zweiter Blick auf die Abhängigkeiten. Das Paket java-21-openjdk-devel zieht auf AlmaLinux 9 eine erstaunlich große Kette grafischer Pakete nach, darunter webkit2gtk3-jsc, xorg-x11-fonts, xdg-desktop-portal und wireplumber. Auf einem Server ohne Oberfläche will man das nicht. Prüfen Sie deshalb vorher mit dnf install --assumeno, was tatsächlich mitkommt, und bleiben Sie bei java-21-openjdk-headless, solange Sie nichts kompilieren müssen.

Minecraft: Spielversion zu Java-Version

Minecraft ist der häufigste Grund, warum überhaupt jemand Java auf einen Server bringt, und gleichzeitig der Bereich mit den härtesten Anforderungen. Die Zuordnung ist eindeutig:

Zwei Dinge dazu, die in den meisten Tabellen fehlen. Erstens: mit 26.1 hat Minecraft das alte 1.x-Schema verlassen und ist auf ein Jahresschema umgestiegen, 26.1 ist also die erste Ausgabe des Jahres 2026. 1.21.11 war die letzte Version, die mit Java 21 auskommt.

Zweitens: das "oder neuer" gilt für den Vanilla-Server. Sobald Modloader im Spiel sind, gilt es nicht mehr zuverlässig. Ein Forge-Server für 1.20.1 ist auf Java 17 gebaut, und ihn auf Java 21 zu stellen ist eine der häufigsten Ursachen für Abstürze direkt beim Start, obwohl die Zahl doch "größer" ist. Bei modded Servern nehmen Sie exakt die Version, die der Modpack-Ersteller nennt.

Die praktische Umsetzung steht in unseren Anleitungen Minecraft-Server auf Debian installieren und Minecraft-Server automatisch starten.

Andere Serveranwendungen und ihre Ansprüche

Jenseits von Minecraft gelten grob diese Regeln:

• Apache Tomcat: 9.0.x läuft ab Java 8, 10.1.x verlangt mindestens Java 11, 11.0.x verlangt mindestens Java 17. Alle drei aktuell gepflegten Zweige laufen auf Java 17 sauber.
• Elasticsearch und OpenSearch: bringen eine eigene JVM mit. Installieren Sie dort kein System-Java und setzen Sie kein globales JAVA_HOME, das die mitgelieferte JVM überschreibt. Das ist eine klassische Fehlerquelle nach einem "Aufräumen" der Java-Installation.
• Jenkins: aktuelle Versionen setzen mindestens Java 17 voraus und laufen auf Java 21.
• Keycloak, Kafka, Solr, Nexus: orientieren sich am jeweils vorletzten LTS. Prüfen Sie die Release Notes der konkreten Version, diese Projekte ziehen die Untergrenze regelmäßig nach.

Nicht jede Serversoftware, die man mit Java verbindet, braucht tatsächlich eines. Der TeamSpeak-3-Server zum Beispiel ist ein natives Binary und kommt ohne JVM aus.

Mehrere Java-Versionen parallel betreiben und umschalten

Auf Debian und Ubuntu können Sie beliebig viele OpenJDK-Pakete gleichzeitig installieren. Sie landen jeweils in einem eigenen Verzeichnis unter /usr/lib/jvm/ und stören sich nicht gegenseitig:

apt install -y openjdk-21-jre-headless openjdk-25-jre-headless
ls /usr/lib/jvm/

Was sie sich teilen, ist genau eine Datei: /usr/bin/java. Die ist ein Symlink, den das Alternativen-System verwaltet. Anzeigen lassen sich die Kandidaten so:

update-alternatives --list java
update-alternatives --display java

Diese Schreibweise mit dem Namen hinter --list ist Debian-spezifisch, auf der Red-Hat-Familie sieht sie anders aus, dazu weiter unten mehr. Die Ausgabe von --display ist die wichtigere von beiden. Sie zeigt nicht nur die Pfade, sondern auch den Modus (auto oder manual) und die Priorität jedes Eintrags. Umschalten geht interaktiv mit update-alternatives --config java und einer Nummernauswahl, in Skripten besser fest:

update-alternatives --set java /usr/lib/jvm/java-21-openjdk-amd64/bin/java
java -version

Schreiben Sie den Pfad dabei nie aus einem fremden Tutorial ab, sondern nehmen Sie ihn aus update-alternatives --list java. Der oben gezeigte Pfad gilt für OpenJDK aus dem Distributionspaket. Wer dem Temurin-Abschnitt weiter unten folgt, hat dieses Verzeichnis gar nicht, dort heißt es /usr/lib/jvm/temurin-21-jre-amd64/bin/java, und der Befehl bricht mit alternative path ... doesn't exist ab.

Wenn Sie auch kompilieren, muss javac separat umgestellt werden. Das wird gern vergessen und führt zu der absurden Situation, dass mit Java 25 kompiliert und mit Java 21 gestartet wird:

update-alternatives --set javac /usr/lib/jvm/java-21-openjdk-amd64/bin/javac
javac -version

Die Falle, die Sie nachts kostet

Solange java im Modus auto steht, gewinnt immer die höchste Priorität, und die höchste Priorität hat die neueste installierte Version. Installieren Sie also Monate später openjdk-25 dazu, weil ein anderer Dienst es braucht, springt /usr/bin/java beim nächsten Paketvorgang stillschweigend auf 25 um. Ihr Minecraft-Server, der bis dahin auf 21 lief, startet nach dem nächsten Neustart auf einer JVM, die Sie nie ausgewählt haben.

update-alternatives --set schaltet den Eintrag auf manual und friert ihn damit ein. Das ist der eigentliche Zweck des Befehls. Zurück in den Automatikmodus kommen Sie mit:

update-alternatives --auto java

Der robustere Weg für Dienste ist trotzdem, sich gar nicht auf /usr/bin/java zu verlassen. Tragen Sie in Ihrer systemd-Unit den vollen Pfad ein, dann ist die Versionswahl pro Dienst festgeschrieben und unabhängig von jedem Alternativen-Wechsel:

ExecStart=/usr/lib/jvm/java-21-openjdk-amd64/bin/java -Xms2G -Xmx4G -jar server.jar nogui

Wie so eine Unit vollständig aussieht, steht in systemd-Service erstellen. Genau dieser absolute Pfad ist übrigens auch der Grund, warum ein Dienst nach einem Java-Wechsel manchmal nicht mitwandert: update-alternatives fasst ihn schlicht nicht an.

Auf AlmaLinux, Rocky Linux, RHEL und Oracle Linux heißt das Werkzeug alternatives, und update-alternatives ist dort nur ein Symlink darauf. Gleich funktioniert es aber nicht: Dieses --list nimmt kein Argument. Ein kopiertes update-alternatives --list java gibt dort nur den Hilfetext aus und endet mit Rückgabewert 2. Richtig ist eine dieser beiden Zeilen:

alternatives --list | grep java
alternatives --display java

Auch die Ausgabe von --display weicht ab: Statt java - auto mode steht dort java - status is auto. Die Pfade tragen auf der Red-Hat-Familie zudem die vollständige Versionsnummer, also etwa /usr/lib/jvm/java-21-openjdk-21.0.11.0.10-1.el9.x86_64, und nicht die kurze Debian-Form java-21-openjdk-amd64. Nur AlmaLinux 10 legt zusätzlich einen kurzen Symlink java-21-openjdk an.

Und die Automatik verhält sich dort anders, als man erwartet: Nach der Installation von Java 17 neben einem bereits vorhandenen Java 21 stellte alternatives auf AlmaLinux 9 den Link /usr/bin/java selbsttätig auf 17 um, also auf die ältere Version. Setzen Sie deshalb nach jeder Zusatzinstallation ausdrücklich alternatives --set java <Pfad> und prüfen Sie mit java -version nach.

Wenn die Distribution die Version nicht hat: Temurin

Für die Lücken in der Tabelle oben gibt es eine saubere Antwort: Eclipse Temurin von Adoptium liefert temurin-8 bis temurin-26 für trixie, bookworm, noble und jammy. Damit bekommen Sie Java 21 auch auf Debian 12 und Java 17 auch auf Debian 13, ohne fremde PPAs oder handkopierte Tarballs in /opt.

Beachten Sie dabei, dass apt-key abgekündigt ist. Der Schlüssel gehört nach /etc/apt/keyrings/ und wird über signed-by referenziert:

apt install -y wget gnupg ca-certificates apt-transport-https
install -d -m 0755 /etc/apt/keyrings
wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | tee /etc/apt/keyrings/adoptium.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/adoptium.gpg] https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list
apt update
apt install -y temurin-21-jre

Temurin-Pakete registrieren sich ebenfalls im Alternativen-System, tauchen also in update-alternatives --display java auf und lassen sich mit den OpenJDK-Paketen der Distribution mischen. Ihre Verzeichnisse liegen unter /usr/lib/jvm/temurin-21-jre-amd64 beziehungsweise ähnlich benannt.

Fehlermeldungen im Wortlaut und was sie bedeuten

E: Unable to locate package openjdk-17-jre-headless
Die Version existiert in dieser Distribution nicht. Auf Debian 13 ist das der Normalfall für Java 8, 11 und 17. Kein Tippfehler, kein fehlendes apt update: nehmen Sie Temurin oder eine andere Version.

java.lang.UnsupportedClassVersionError: ... has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
Der Klassiker. Die Anwendung ist für eine neuere JVM gebaut als die, die Sie gestartet haben. Die Zahlen übersetzen sich so:

65.0 gegen 61.0 heißt also im Klartext: die Software will Java 21, Sie haben Java 17 laufen. Bei Minecraft-Servern ab 1.20.5 sehen Sie diesen Fehler häufig verpackt als Error: LinkageError occurred while loading main class net.minecraft.bundler.Main, die eigentliche Ursache steht dann in der Zeile darunter.

java: command not found
Es ist keine JVM installiert, oder Sie haben nur ein JDK-Verzeichnis nach /opt entpackt, ohne es zu registrieren. Prüfen Sie ls /usr/lib/jvm/. Sind dort Verzeichnisse, aber /usr/bin/java fehlt, registrieren Sie den Eintrag nach:

update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-amd64/bin/java 2111

update-alternatives: error: no alternatives for java
Das Alternativen-System kennt gar keinen Kandidaten. Tritt auf, wenn Java von Hand installiert wurde. Gleicher Fix wie oben.

update-alternatives: error: alternative path /usr/lib/jvm/... doesn't exist
Sie haben einen Pfad gesetzt, der inzwischen weg ist, typischerweise nach einer Deinstallation. Achten Sie darauf, dass Debian-Pfade die Architektur enthalten: java-21-openjdk-amd64, nicht java-21-openjdk.

Der Dienst läuft, aber auf der falschen Version.
Sehr wahrscheinlich steht in der systemd-Unit ein absoluter Pfad, oder die Unit setzt ein eigenes JAVA_HOME. Beides überstimmt update-alternatives ohne jede Warnung.

Der Server startet, stirbt aber nach Sekunden ohne verständliche Meldung.
Bei Java-Anwendungen ist das oft kein Versionsproblem, sondern Speichermangel: Der Kernel beendet den Prozess, wenn -Xmx größer gewählt ist als der freie RAM. Dazu passen unsere Artikel Swap einrichten gegen Out of Memory und Festplatte voll unter Linux aufräumen.

Woran Sie erkennen, dass wirklich die richtige Version läuft

Die erste Prüfung ist trivial, aber machen Sie sie trotzdem nach jedem Wechsel:

java -version

Die Ausgabe muss die erwartete Hauptversion nennen, etwa openjdk version "21.0.11". Die zweite Prüfung ist die aussagekräftigere, weil sie den tatsächlich aufgelösten Pfad zeigt und damit auch, ob Sie gerade Temurin oder OpenJDK der Distribution erwischt haben:

readlink -f "$(command -v java)"

Verwenden Sie hier bewusst command -v und nicht which. which ist ein externes Programm, und in der Minimalinstallation von AlmaLinux 9 und 10, Rocky Linux 9 und Oracle Linux 9 ist es gar nicht enthalten. Die Variante mit which endet dort mit which: command not found, gefolgt von readlink: missing operand. command -v ist ein Shell-Builtin und läuft auf allen genannten Distributionen.

Und wenn Sie wissen wollen, was die JVM selbst über ihr Zuhause denkt, weil eine Anwendung JAVA_HOME auswertet:

java -XshowSettings:properties -version

In der Ausgabe interessieren java.home und java.version. Weicht java.home von Ihrer Erwartung ab, ist irgendwo ein JAVA_HOME gesetzt, das gewinnt.

Für einen laufenden Dienst zählt am Ende nur, was der Prozess selbst benutzt. Das lesen Sie direkt aus der Prozessliste, dort steht der volle Pfad der JVM, mit der er gestartet wurde:

ps -eo pid,args | grep '[j]ava'

Sehen Sie dort /usr/lib/jvm/java-21-openjdk-amd64/bin/java, ist die Sache erledigt. Sehen Sie ein blankes java, hängt Ihr Dienst am Alternativen-Symlink und ändert sich mit ihm mit. Für einen Produktivdienst ist das die schlechtere von beiden Varianten.

Wenn Sie einen Server ohnehin gerade frisch aufsetzen, lohnt sich vorher der Blick in unsere Checkliste für neue Rootserver: Java gehört an das Ende dieser Liste, nicht an den Anfang, denn erst mit funktionierendem SSH-Zugang, Firewall und Zeitzone macht die Fehlersuche an einer JVM überhaupt Spaß.

Zusammengefasst

Java 21 ist heute die Standardantwort, Java 25 die zukunftssichere, Java 17 die auslaufende, und Java 8 und 11 sind Migrationsschulden. Entscheidend ist aber nicht die Zahl allein, sondern die Kombination aus Anwendung und Distribution: Debian 12 gibt Ihnen nur 17, Debian 13 nur 21 und 25, Ubuntu gibt Ihnen alles. Wo das Paket fehlt, füllt Temurin die Lücke. Und sobald mehr als eine Version auf der Maschine liegt, gilt: update-alternatives --set statt Automatik, und in systemd-Units besser gleich der absolute Pfad.