Welke Java-versie heb ik nodig? Overzicht voor servers

Java staat zelden om zichzelf op een server. Het staat er omdat een Minecraft-server, een Tomcat, een Jenkins of een zoekindex erom vraagt. Precies daarom luidt de vraag nooit "welke Java is de beste", maar "welke Java verwacht deze ene applicatie, en is die op dit ene besturingssysteem eigenlijk wel te krijgen". Dit artikel beantwoordt beide vragen: met de ondersteuningstermijnen, met een beschikbaarheidstabel die wij in echte containers hebben nagemeten, en met de praktijk van meerdere versies naast elkaar.

De korte versie: welke versie voor welk doel

Hebt u geen tijd, dan is dit de beslissing:

• Nieuw project, vrije keuze: Java 21. Dat is momenteel de breedst ondersteunde LTS-lijn, in Debian 13 en in alle actuele Ubuntu-versies kant-en-klaar verpakt, en praktisch elke actuele serversoftware draait erop.
• Minecraft 1.20.5 tot en met 1.21.11: Java 21. Verplicht, geen speelruimte.
• Minecraft 26.1 en nieuwer: Java 25.
• Oudere applicatie met "Java 17" in de documentatie: neem Java 17, niet "17 of nieuwer". Bij modloaders en systemen met plug-ins klopt "nieuwer" vaak niet.
• Java 8 of 11: alleen nog wanneer een oude applicatie u daartoe dwingt. Beide horen op uw lijst van zaken die vervangen moeten worden.
• Java 25: de nieuwste LTS-lijn, zinvol voor nieuwe deployments, maar controleer vooraf of uw framework er officieel voor is vrijgegeven.

Voor de installatie zelf hebben wij aparte handleidingen: Java 17 installeren op Debian en Java 21 installeren op Debian. Dit artikel vormt het overzicht daarboven.

Wat LTS betekent en hoe lang de versies onderhouden worden

Java verschijnt elk half jaar in een nieuwe hoofdversie. De allermeeste daarvan zijn na precies zes maanden dood: Java 22, 23, 24 en 26 krijgen geen beveiligingsupdate meer zodra de volgende versie er is. Die wilt u niet op een server hebben.

Interessant zijn uitsluitend de LTS-versies (Long Term Support). Die verschijnen sinds 2021 om de twee jaar: 8, 11, 17, 21, 25, en als volgende staat Java 29 gepland voor september 2027. Alleen deze lijnen krijgen jarenlang elk kwartaal beveiligingsupdates.

Belangrijk is het onderscheid tussen Oracle en de vrije builds. Voor serverbeheer grijpt u in de regel naar OpenJDK uit het distributiepakket of naar Eclipse Temurin. Beide zijn gratis te gebruiken, en het onderhoud loopt daar deels duidelijk langer door dan bij de gratis licentie van Oracle.

De regel voor Java 17 verrast velen: nog maar tot oktober 2027. Java 17 voelt nieuw aan, maar is al de voorlaatste LTS-generatie. Wie vandaag een systeem opzet dat drie jaar moet draaien, plant beter meteen met 21 of 25.

Welke Java-versie uw distributie in de eigen repository heeft

Hier gaan de meeste handleidingen op internet de mist in: ze schrijven "apt install openjdk-17-jre-headless" en gaan ervan uit dat dat overal werkt. Dat is niet zo. Wij hebben de pakketsituatie op 27 juli 2026 in verse containers nagemeten.

Lees de Debian-kolommen twee keer. Debian 12 kent uitsluitend Java 17. Debian 13 kent Java 17 niet meer, maar wel 21 en 25. In de officiële Debian-bronnen bestaat er dus geen enkele versie die op beide releases aanwezig is. Wie een deploymentscript schrijft dat zowel op bookworm als op trixie moet draaien, kan niet op één pakket vertrouwen.

Ubuntu is in dit opzicht aangenamer: daar liggen alle vijf LTS-lijnen naast elkaar in de repository, op 22.04 net zo goed als op 24.04. Hebt u een systeem nodig waarop een oude applicatie met Java 8 en een moderne service met Java 21 tegelijk draaien, dan is Ubuntu de kortste weg.

Controleer bij twijfel zelf in plaats van te gokken:

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

Staat er achter "Kandidaat" een (geen), op een Engelstalig systeem achter "Candidate" een (none), dan bestaat het pakket op deze distributie niet. Bij de Red Hat-familie (AlmaLinux, Rocky, RHEL, Oracle Linux) heten de pakketten anders, daar maakt u de lijst zo:

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

Neem voor het overzicht dnf list en niet dnf list available. Dat laatste verbergt de al geïnstalleerde pakketten, dus na het installeren van Java 21 duikt Java 21 niet meer in de lijst op en zoekt u op de verkeerde plek. De situatie in de Red Hat-familie, eveneens in verse containers nagemeten:

AlmaLinux 10 heeft dus dezelfde streep getrokken als Debian 13 en alles onder 21 laten vallen. Een dnf install java-17-openjdk-headless eindigt daar met No match for argument.

headless of niet, JRE of JDK

Op een server neemt u altijd de -headless-variant. Die laat de grafische bibliotheken weg en sleept daardoor geen X11-afhankelijkheden mee, wat op een rootserver tientallen overbodige pakketten scheelt. En -jre-headless volstaat zolang u alleen kant-en-klare JAR-bestanden uitvoert. Pas wanneer u zelf compileert of een tool javac aanroept, hebt u openjdk-21-jdk-headless nodig.

Bij de Red Hat-familie loont hier een tweede blik op de afhankelijkheden. Het pakket java-21-openjdk-devel sleept op AlmaLinux 9 een verrassend lange keten grafische pakketten mee, waaronder webkit2gtk3-jsc, xorg-x11-fonts, xdg-desktop-portal en wireplumber. Op een server zonder grafische omgeving wilt u dat niet. Controleer daarom vooraf met dnf install --assumeno wat er werkelijk meekomt, en blijf bij java-21-openjdk-headless zolang u niets hoeft te compileren.

Minecraft: spelversie tegenover Java-versie

Minecraft is de vaakst voorkomende reden dat er Java op een server terechtkomt, en tegelijk het terrein met de strengste eisen. De toewijzing is eenduidig:

Twee dingen daarbij die in de meeste tabellen ontbreken. Ten eerste: met 26.1 heeft Minecraft het oude 1.x-schema verlaten en is het overgestapt op een jaarschema, 26.1 is dus de eerste uitgave van het jaar 2026. 1.21.11 was de laatste versie die genoeg heeft aan Java 21.

Ten tweede: dat "of nieuwer" geldt voor de vanillaserver. Zodra er modloaders in het spel zijn, gaat het niet meer betrouwbaar op. Een Forge-server voor 1.20.1 is op Java 17 gebouwd, en hem op Java 21 zetten is een van de vaakst voorkomende oorzaken van crashes direct bij de start, ook al is het getal "groter". Bij servers met mods neemt u exact de versie die de maker van het modpack noemt.

De praktische uitvoering staat in onze handleidingen Minecraft-server installeren op Debian en Minecraft-server automatisch starten.

Andere serverapplicaties en hun eisen

Buiten Minecraft gelden grofweg deze regels:

• Apache Tomcat: 9.0.x draait vanaf Java 8, 10.1.x vereist minstens Java 11, 11.0.x vereist minstens Java 17. Alle drie de actueel onderhouden takken draaien probleemloos op Java 17.
• Elasticsearch en OpenSearch: brengen een eigen JVM mee. Installeer daar geen systeem-Java en stel geen globale JAVA_HOME in die de meegeleverde JVM overschrijft. Dat is een klassieke foutbron na het "opruimen" van de Java-installatie.
• Jenkins: actuele versies vereisen minstens Java 17 en draaien op Java 21.
• Keycloak, Kafka, Solr, Nexus: richten zich telkens naar de voorlaatste LTS. Controleer de release notes van de concrete versie, want deze projecten trekken de ondergrens regelmatig op.

Niet elke serversoftware die men met Java associeert, heeft er ook werkelijk een nodig. De TeamSpeak-3-server bijvoorbeeld is een native binary en heeft helemaal geen JVM nodig.

Meerdere Java-versies naast elkaar draaien en omschakelen

Op Debian en Ubuntu kunt u willekeurig veel OpenJDK-pakketten tegelijk installeren. Elk pakket belandt in een eigen map onder /usr/lib/jvm/ en ze zitten elkaar niet in de weg:

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

Wat ze wel delen, is precies één bestand: /usr/bin/java. Dat is een symlink die door het alternatives-systeem wordt beheerd. De kandidaten laten zich zo tonen:

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

Deze schrijfwijze met de naam achter --list is Debian-specifiek, bij de Red Hat-familie ziet die er anders uit, daarover verderop meer. De uitvoer van --display is de belangrijkste van de twee. Die toont niet alleen de paden, maar ook de modus (auto of manual) en de prioriteit van elk item. Omschakelen gaat interactief met update-alternatives --config java en een nummerkeuze, in scripts beter vast:

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

Neem het pad daarbij nooit over uit een vreemde tutorial, maar haal het uit update-alternatives --list java. Het pad hierboven geldt voor OpenJDK uit het distributiepakket. Wie het Temurin-hoofdstuk verderop volgt, heeft die map helemaal niet, daar heet het /usr/lib/jvm/temurin-21-jre-amd64/bin/java, en het commando breekt af met alternative path ... doesn't exist.

Compileert u ook, dan moet javac apart worden omgezet. Dat wordt graag vergeten en leidt tot de absurde situatie dat er met Java 25 wordt gecompileerd en met Java 21 wordt gestart:

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

De valkuil die u nachtrust kost

Zolang java in de modus auto staat, wint altijd de hoogste prioriteit, en de hoogste prioriteit heeft de nieuwste geïnstalleerde versie. Installeert u maanden later dus openjdk-25 erbij omdat een andere service dat nodig heeft, dan springt /usr/bin/java bij de volgende pakketbewerking stilzwijgend over naar 25. Uw Minecraft-server, die tot dan toe op 21 draaide, start na de volgende herstart op een JVM die u nooit hebt gekozen.

update-alternatives --set zet het item op manual en bevriest het daarmee. Dat is het eigenlijke doel van dat commando. Terug naar de automatische modus komt u met:

update-alternatives --auto java

De robuustere weg voor services is toch om helemaal niet op /usr/bin/java te vertrouwen. Zet in uw systemd-unit het volledige pad, dan ligt de versiekeuze per service vast en staat die los van elke wisseling in het alternatives-systeem:

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

Hoe zo'n unit er volledig uitziet, staat in systemd-service aanmaken. Precies dat absolute pad is trouwens ook de reden waarom een service na een Java-wissel soms niet meeverhuist: update-alternatives raakt het domweg niet aan.

Op AlmaLinux, Rocky Linux, RHEL en Oracle Linux heet het gereedschap alternatives, en update-alternatives is daar alleen een symlink daarnaartoe. Het werkt er echter niet op dezelfde manier: die --list accepteert geen argument. Een gekopieerd update-alternatives --list java geeft daar alleen de helptekst en eindigt met retourwaarde 2. Correct is een van deze twee regels:

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

Ook de uitvoer van --display wijkt af: in plaats van java - auto mode staat er java - status is auto. De paden dragen bij de Red Hat-familie bovendien het volledige versienummer, dus bijvoorbeeld /usr/lib/jvm/java-21-openjdk-21.0.11.0.10-1.el9.x86_64, en niet de korte Debian-vorm java-21-openjdk-amd64. Alleen AlmaLinux 10 legt daarnaast een korte symlink java-21-openjdk aan.

En de automatische modus gedraagt zich daar anders dan u verwacht: na de installatie van Java 17 naast een al aanwezige Java 21 zette alternatives op AlmaLinux 9 de link /usr/bin/java eigenhandig om naar 17, dus naar de oudere versie. Zet daarom na elke extra installatie uitdrukkelijk alternatives --set java <pad> en controleer het na met java -version.

Als de distributie de versie niet heeft: Temurin

Voor de gaten in de tabel hierboven bestaat een nette oplossing: Eclipse Temurin van Adoptium levert temurin-8 tot en met temurin-26 voor trixie, bookworm, noble en jammy. Daarmee krijgt u Java 21 ook op Debian 12 en Java 17 ook op Debian 13, zonder vreemde PPA's of met de hand gekopieerde tarballs in /opt.

Houd er daarbij rekening mee dat apt-key is afgeschaft. De sleutel hoort in /etc/apt/keyrings/ en wordt via signed-by gerefereerd:

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-pakketten registreren zich eveneens in het alternatives-systeem, duiken dus op in update-alternatives --display java en laten zich met de OpenJDK-pakketten van de distributie combineren. Hun mappen liggen onder /usr/lib/jvm/temurin-21-jre-amd64 of onder een vergelijkbare naam.

Foutmeldingen letterlijk en wat ze betekenen

E: Unable to locate package openjdk-17-jre-headless
Die versie bestaat niet in deze distributie. Op Debian 13 is dat het normale geval voor Java 8, 11 en 17. Geen typefout, geen ontbrekende apt update: neem Temurin of een andere versie.

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
De klassieker. De applicatie is gebouwd voor een nieuwere JVM dan de JVM die u hebt gestart. De getallen vertalen zich zo:

65.0 tegenover 61.0 betekent dus in gewone taal: de software wil Java 21, u draait Java 17. Bij Minecraft-servers vanaf 1.20.5 ziet u deze fout vaak verpakt als Error: LinkageError occurred while loading main class net.minecraft.bundler.Main, de eigenlijke oorzaak staat dan op de regel eronder.

java: command not found
Er is geen JVM geïnstalleerd, of u hebt alleen een JDK-map naar /opt uitgepakt zonder die te registreren. Controleer ls /usr/lib/jvm/. Staan daar mappen, maar ontbreekt /usr/bin/java, registreer het item dan alsnog:

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

update-alternatives: error: no alternatives for java
Het alternatives-systeem kent helemaal geen kandidaat. Treedt op wanneer Java met de hand is geïnstalleerd. Dezelfde oplossing als hierboven.

update-alternatives: error: alternative path /usr/lib/jvm/... doesn't exist
U hebt een pad ingesteld dat inmiddels weg is, typisch na het verwijderen van een pakket. Let erop dat Debian-paden de architectuur bevatten: java-21-openjdk-amd64, niet java-21-openjdk.

De service draait, maar op de verkeerde versie.
Zeer waarschijnlijk staat er in de systemd-unit een absoluut pad, of stelt de unit een eigen JAVA_HOME in. Beide overrulen update-alternatives zonder enige waarschuwing.

De server start, maar sterft na enkele seconden zonder begrijpelijke melding.
Bij Java-applicaties is dat vaak geen versieprobleem, maar geheugengebrek: de kernel beëindigt het proces wanneer -Xmx groter is gekozen dan het vrije RAM. Daarbij passen onze artikelen Swap instellen tegen Out of Memory en Schijf vol onder Linux opruimen.

Controleren of werkelijk de juiste versie draait

De eerste controle is triviaal, maar voer die toch na elke wissel uit:

java -version

De uitvoer moet de verwachte hoofdversie noemen, bijvoorbeeld openjdk version "21.0.11". De tweede controle zegt meer, want die toont het werkelijk opgeloste pad en daarmee ook of u nu Temurin of de OpenJDK van de distributie te pakken hebt:

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

Gebruik hier bewust command -v en niet which. which is een extern programma en ontbreekt in de minimale installatie van AlmaLinux 9 en 10, Rocky Linux 9 en Oracle Linux 9 volledig. De variant met which eindigt daar met which: command not found, gevolgd door readlink: missing operand. command -v is een shell-builtin en draait op alle genoemde distributies.

En wilt u weten wat de JVM zelf over haar thuisbasis denkt, omdat een applicatie JAVA_HOME uitleest:

java -XshowSettings:properties -version

In de uitvoer zijn java.home en java.version van belang. Wijkt java.home af van uw verwachting, dan staat er ergens een JAVA_HOME ingesteld die het wint.

Voor een draaiende service telt uiteindelijk alleen wat het proces zelf gebruikt. Dat leest u direct uit de processenlijst, daar staat het volledige pad van de JVM waarmee het is gestart:

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

Ziet u daar /usr/lib/jvm/java-21-openjdk-amd64/bin/java, dan is de zaak rond. Ziet u een kaal java, dan hangt uw service aan de alternatives-symlink en verandert die mee. Voor een productieservice is dat de slechtste van de twee varianten.

Bent u toch net bezig een server nieuw op te zetten, dan loont vooraf een blik in onze checklist voor nieuwe rootservers: Java hoort aan het einde van die lijst, niet aan het begin, want pas met werkende SSH-toegang, firewall en tijdzone is het foutzoeken aan een JVM een beetje te doen.

Samengevat

Java 21 is vandaag het standaardantwoord, Java 25 het toekomstvaste, Java 17 het aflopende, en Java 8 en 11 zijn migratieschuld. Doorslaggevend is echter niet het getal alleen, maar de combinatie van applicatie en distributie: Debian 12 geeft u alleen 17, Debian 13 alleen 21 en 25, Ubuntu geeft u alles. Waar het pakket ontbreekt, vult Temurin het gat. En zodra er meer dan één versie op de machine staat, geldt: update-alternatives --set in plaats van de automatische modus, en in systemd-units liever meteen het absolute pad.