Quelle version de Java choisir ? Vue d'ensemble pour serveurs

Sur un serveur, Java est rarement une fin en soi. Il est là parce qu'un serveur Minecraft, un Tomcat, un Jenkins ou un index de recherche l'exige. C'est exactement pour cette raison que la question n'est jamais « quel est le meilleur Java », mais « quel Java cette application précise attend-elle, et puis-je seulement l'obtenir sur ce système d'exploitation précis ». Cet article répond aux deux : avec les calendriers de support, avec un tableau de disponibilité que nous avons mesuré nous-mêmes dans de vrais conteneurs (containers), et avec la pratique de l'exploitation de plusieurs versions en parallèle.

En bref : quelle version pour quel usage

Si vous êtes pressé, voici la décision :

• Nouveau projet, choix libre : Java 21. C'est actuellement la ligne LTS la plus largement prise en charge, déjà empaquetée dans Debian 13 et dans toutes les versions récentes d'Ubuntu, et pratiquement tous les logiciels serveur actuels tournent dessus.
• Minecraft 1.20.5 à 1.21.11 : Java 21. Obligatoire, aucune marge de manœuvre.
• Minecraft 26.1 et plus récent : Java 25.
• Application plus ancienne dont la documentation indique « Java 17 » : prenez Java 17, et non « 17 ou plus récent ». Avec les modloaders et les systèmes de plugins, le « plus récent » est souvent faux.
• Java 8 ou 11 : uniquement si une application héritée l'impose. Les deux ont leur place sur votre liste des choses à remplacer.
• Java 25 : la ligne LTS la plus récente, pertinente pour de nouveaux déploiements, mais vérifiez d'abord que votre framework est officiellement validé dessus.

Pour l'installation proprement dite, nous avons des guides dédiés : Installer Java 17 sur Debian et Installer Java 21 sur Debian. Le présent article en est la carte d'ensemble.

Ce que signifie LTS et pendant combien de temps les versions sont maintenues

Java sort une nouvelle version majeure tous les six mois. La grande majorité d'entre elles sont mortes au bout de six mois exactement : Java 22, 23, 24 et 26 ne reçoivent plus la moindre mise à jour de sécurité dès que la version suivante arrive. Sur un serveur, vous n'en voulez pas.

Seules les versions LTS (Long Term Support) présentent un intérêt. Depuis 2021, elles sortent tous les deux ans : 8, 11, 17, 21, 25, et la suivante, Java 29, est prévue pour septembre 2027. Ces lignes sont les seules à recevoir des mises à jour de sécurité trimestrielles pendant des années.

La distinction entre Oracle et les builds libres est importante. Pour un usage serveur, vous prendrez en règle générale OpenJDK issu du paquet de la distribution, ou bien Eclipse Temurin. Les deux sont utilisables gratuitement, et la maintenance y court parfois nettement plus longtemps qu'avec la licence gratuite d'Oracle.

La ligne consacrée à Java 17 en surprend plus d'un : seulement jusqu'à octobre 2027. Java 17 donne l'impression d'être récent, mais c'est déjà l'avant-dernière génération LTS. Si vous montez aujourd'hui un système censé tourner trois ans, mieux vaut planifier tout de suite avec 21 ou 25.

Quelle version de Java votre distribution propose dans son propre dépôt

C'est là que la plupart des guides trouvés sur le web échouent : ils écrivent « apt install openjdk-17-jre-headless » et supposent que cela fonctionne partout. Ce n'est pas le cas. Nous avons mesuré l'état des paquets le 27/07/2026 dans des conteneurs neufs.

Relisez deux fois les colonnes Debian. Debian 12 ne connaît que Java 17. Debian 13 ne connaît plus Java 17, mais propose 21 et 25. Dans les sources officielles de Debian, il n'existe donc pas une seule version présente sur les deux releases. Si vous écrivez un script de déploiement censé tourner à la fois sur bookworm et sur trixie, vous ne pouvez vous fier à aucun paquet.

Ubuntu est plus agréable sur ce point : les cinq lignes LTS y cohabitent dans le dépôt, aussi bien sur 22.04 que sur 24.04. Si vous avez besoin d'un système où une application héritée en Java 8 et un service moderne en Java 21 tournent en même temps, Ubuntu est le raccourci.

En cas de doute, vérifiez vous-même plutôt que de deviner :

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

Si la ligne « Candidat », ou « Candidate » en anglais, affiche (none), c'est que le paquet n'existe pas sur cette distribution. Dans la famille Red Hat (AlmaLinux, Rocky, RHEL, Oracle Linux), les paquets portent d'autres noms, et vous les listez ainsi :

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

Pour la vue d'ensemble, prenez dnf list et non dnf list available. Cette seconde forme masque les paquets déjà installés : une fois Java 21 installé, Java 21 disparaît de la liste, et vous cherchez au mauvais endroit. La situation dans la famille Red Hat, mesurée elle aussi dans des conteneurs neufs :

AlmaLinux 10 a donc opéré la même coupe que Debian 13 et abandonné tout ce qui se situe en dessous de 21. Un dnf install java-17-openjdk-headless s'y termine par No match for argument.

headless ou non, JRE ou JDK

Sur un serveur, prenez toujours la variante -headless. Elle se passe des bibliothèques graphiques et n'entraîne donc aucune dépendance X11, ce qui économise des dizaines de paquets superflus sur un serveur root. Et -jre-headless suffit tant que vous vous contentez d'exécuter des fichiers JAR déjà compilés. Ce n'est que si vous compilez vous-même, ou si un outil appelle javac, que vous avez besoin de openjdk-21-jdk-headless.

Dans la famille Red Hat, un second regard sur les dépendances s'impose à ce stade. Sur AlmaLinux 9, le paquet java-21-openjdk-devel entraîne une chaîne étonnamment longue de paquets graphiques, dont webkit2gtk3-jsc, xorg-x11-fonts, xdg-desktop-portal et wireplumber. Sur un serveur sans interface graphique, personne n'en veut. Vérifiez donc au préalable avec dnf install --assumeno ce qui arrive réellement, et restez sur java-21-openjdk-headless tant que vous n'avez rien à compiler.

Minecraft : version du jeu et version de Java

Minecraft est la raison la plus fréquente pour laquelle quelqu'un installe Java sur un serveur, et c'est en même temps le domaine aux exigences les plus strictes. La correspondance est sans ambiguïté :

Deux précisions à ce sujet, absentes de la plupart des tableaux. Premièrement : avec 26.1, Minecraft a quitté l'ancien schéma 1.x pour passer à une numérotation annuelle. 26.1 est donc la première édition de l'année 2026. 1.21.11 était la dernière version à se contenter de Java 21.

Deuxièmement : le « ou plus récent » vaut pour le serveur vanilla. Dès que des modloaders entrent en jeu, il ne tient plus de manière fiable. Un serveur Forge pour 1.20.1 est construit sur Java 17, et le basculer sur Java 21 est l'une des causes les plus fréquentes de plantage dès le démarrage, bien que le chiffre soit pourtant « plus grand ». Sur un serveur moddé, prenez exactement la version indiquée par l'auteur du modpack.

La mise en pratique est décrite dans nos guides Installer un serveur Minecraft sur Debian et Démarrer automatiquement un serveur Minecraft.

Les autres applications serveur et leurs exigences

Au-delà de Minecraft, ces règles s'appliquent en gros :

• Apache Tomcat : 9.0.x tourne à partir de Java 8, 10.1.x exige au minimum Java 11, 11.0.x exige au minimum Java 17. Les trois branches actuellement maintenues tournent proprement sur Java 17.
• Elasticsearch et OpenSearch : ils embarquent leur propre JVM. N'y installez pas de Java système et ne définissez aucun JAVA_HOME global qui écraserait la JVM fournie. C'est une source d'erreur classique après un « nettoyage » de l'installation Java.
• Jenkins : les versions actuelles exigent au minimum Java 17 et tournent sur Java 21.
• Keycloak, Kafka, Solr, Nexus : ils s'alignent sur l'avant-dernière LTS. Consultez les release notes de la version concernée, ces projets relèvent régulièrement le plancher.

Tous les logiciels serveur que l'on associe à Java n'en ont pas réellement besoin. Le serveur TeamSpeak 3, par exemple, est un binaire natif et se passe de JVM.

Faire tourner plusieurs versions de Java en parallèle et basculer entre elles

Sur Debian et Ubuntu, vous pouvez installer autant de paquets OpenJDK que vous le voulez en même temps. Chacun atterrit dans son propre répertoire sous /usr/lib/jvm/ et ils ne se gênent pas mutuellement :

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

Ce qu'ils partagent, c'est exactement un fichier : /usr/bin/java. Il s'agit d'un lien symbolique géré par le système d'alternatives. Voici comment afficher les candidats :

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

Cette écriture, avec le nom placé derrière --list, est propre à Debian. Dans la famille Red Hat, elle est différente, nous y revenons plus bas. La sortie de --display est la plus utile des deux. Elle montre non seulement les chemins, mais aussi le mode (auto ou manual) et la priorité de chaque entrée. La bascule se fait de façon interactive avec update-alternatives --config java et un choix par numéro, mais dans un script, mieux vaut la figer :

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

Ne recopiez jamais ce chemin depuis un tutoriel trouvé ailleurs, reprenez-le de update-alternatives --list java. Le chemin montré ci-dessus vaut pour OpenJDK issu du paquet de la distribution. Si vous suivez la section Temurin plus bas, ce répertoire n'existe pas chez vous : il s'appelle alors /usr/lib/jvm/temurin-21-jre-amd64/bin/java, et la commande s'interrompt avec alternative path ... doesn't exist.

Si vous compilez également, javac doit être basculé séparément. On l'oublie volontiers, ce qui mène à la situation absurde d'une compilation en Java 25 pour un démarrage en Java 21 :

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

Le piège qui vous coûtera une nuit

Tant que java reste en mode auto, c'est toujours la priorité la plus élevée qui l'emporte, et cette priorité revient à la version installée la plus récente. Si vous ajoutez donc openjdk-25 des mois plus tard parce qu'un autre service en a besoin, /usr/bin/java bascule silencieusement sur 25 lors de la prochaine opération de paquets. Votre serveur Minecraft, qui tournait jusque-là sur 21, démarrera après le prochain redémarrage sur une JVM que vous n'avez jamais choisie.

update-alternatives --set fait passer l'entrée en manual et la gèle ainsi. C'est la véritable raison d'être de cette commande. Pour revenir au mode automatique :

update-alternatives --auto java

La voie la plus robuste pour les services reste malgré tout de ne pas dépendre du tout de /usr/bin/java. Inscrivez le chemin complet dans votre unité systemd : le choix de la version est alors figé service par service et indépendant de toute bascule d'alternatives :

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

À quoi ressemble une telle unité dans son intégralité, c'est expliqué dans Créer un service systemd. C'est d'ailleurs précisément ce chemin absolu qui explique qu'un service ne suive parfois pas un changement de Java : update-alternatives n'y touche tout simplement pas.

Sur AlmaLinux, Rocky Linux, RHEL et Oracle Linux, l'outil s'appelle alternatives, et update-alternatives n'y est qu'un lien symbolique vers celui-ci. Mais il ne fonctionne pas pareil : ce --list ne prend aucun argument. Un update-alternatives --list java copié tel quel n'y affiche que le texte d'aide et se termine avec le code de retour 2. Voici les deux écritures correctes :

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

La sortie de --display diffère elle aussi : au lieu de java - auto mode, on y lit java - status is auto. Dans la famille Red Hat, les chemins portent en outre le numéro de version complet, par exemple /usr/lib/jvm/java-21-openjdk-21.0.11.0.10-1.el9.x86_64, et non la forme Debian courte java-21-openjdk-amd64. Seul AlmaLinux 10 crée en plus un lien symbolique court java-21-openjdk.

Et l'automatisme s'y comporte autrement qu'on ne l'attend : après l'installation de Java 17 à côté d'un Java 21 déjà présent, alternatives a basculé de lui-même le lien /usr/bin/java sur 17 sous AlmaLinux 9, donc sur la version la plus ancienne. Après chaque installation supplémentaire, définissez donc explicitement alternatives --set java <chemin> et contrôlez avec java -version.

Quand la distribution n'a pas la version : Temurin

Il existe une réponse propre aux trous du tableau ci-dessus : Eclipse Temurin, d'Adoptium, fournit temurin-8 à temurin-26 pour trixie, bookworm, noble et jammy. Vous obtenez ainsi Java 21 même sur Debian 12 et Java 17 même sur Debian 13, sans PPA tiers ni archives tar recopiées à la main dans /opt.

Notez au passage que apt-key est déprécié. La clé a sa place dans /etc/apt/keyrings/ et se référence via signed-by :

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

Les paquets Temurin s'enregistrent eux aussi dans le système d'alternatives : ils apparaissent donc dans update-alternatives --display java et se laissent mélanger avec les paquets OpenJDK de la distribution. Leurs répertoires se trouvent sous /usr/lib/jvm/temurin-21-jre-amd64, ou sous un nom similaire.

Les messages d'erreur au mot près et ce qu'ils signifient

E: Unable to locate package openjdk-17-jre-headless
La version n'existe pas dans cette distribution. Sur Debian 13, c'est le cas normal pour Java 8, 11 et 17. Ni faute de frappe, ni apt update oublié : prenez Temurin ou une autre 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
Le grand classique. L'application est construite pour une JVM plus récente que celle que vous avez démarrée. Les chiffres se traduisent ainsi :

65.0 contre 61.0 signifie donc, en clair : le logiciel veut Java 21, vous faites tourner Java 17. Sur les serveurs Minecraft à partir de 1.20.5, vous verrez souvent cette erreur emballée sous la forme Error: LinkageError occurred while loading main class net.minecraft.bundler.Main, la cause réelle figurant alors à la ligne du dessous.

java: command not found
Aucune JVM n'est installée, ou bien vous avez seulement décompressé un répertoire JDK dans /opt sans l'enregistrer. Vérifiez avec ls /usr/lib/jvm/. S'il s'y trouve des répertoires alors que /usr/bin/java manque, enregistrez l'entrée après coup :

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

update-alternatives: error: no alternatives for java
Le système d'alternatives ne connaît aucun candidat. Cela survient quand Java a été installé à la main. Même correctif que ci-dessus.

update-alternatives: error: alternative path /usr/lib/jvm/... doesn't exist
Vous avez défini un chemin qui a disparu entre-temps, typiquement après une désinstallation. Veillez à ce que les chemins Debian contiennent l'architecture : java-21-openjdk-amd64, et non java-21-openjdk.

Le service tourne, mais sur la mauvaise version.
Très probablement, un chemin absolu figure dans l'unité systemd, ou bien l'unité définit son propre JAVA_HOME. Dans les deux cas, cela l'emporte sur update-alternatives sans le moindre avertissement.

Le serveur démarre, mais meurt au bout de quelques secondes sans message compréhensible.
Avec les applications Java, ce n'est souvent pas un problème de version, mais un manque de mémoire : le noyau tue le processus quand -Xmx est réglé plus haut que la RAM libre. Nos articles Configurer le swap contre l'Out of Memory et Nettoyer un disque plein sous Linux complètent le sujet.

Comment vérifier que c'est bien la bonne version qui tourne

La première vérification est triviale, faites-la malgré tout après chaque bascule :

java -version

La sortie doit indiquer la version majeure attendue, par exemple openjdk version "21.0.11". La deuxième vérification est la plus parlante, car elle montre le chemin réellement résolu, et donc aussi si vous êtes tombé sur Temurin ou sur l'OpenJDK de la distribution :

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

Employez ici délibérément command -v et non which. which est un programme externe, et il n'est tout simplement pas inclus dans l'installation minimale d'AlmaLinux 9 et 10, de Rocky Linux 9 et d'Oracle Linux 9. La variante avec which s'y termine par which: command not found, suivi de readlink: missing operand. command -v est un builtin du shell et fonctionne sur toutes les distributions citées.

Et si vous voulez savoir ce que la JVM pense elle-même de son propre domicile, parce qu'une application exploite JAVA_HOME :

java -XshowSettings:properties -version

Dans la sortie, ce sont java.home et java.version qui comptent. Si java.home ne correspond pas à ce que vous attendiez, c'est qu'un JAVA_HOME est défini quelque part et qu'il l'emporte.

Pour un service en cours d'exécution, seul compte au final ce que le processus utilise lui-même. Vous le lisez directement dans la liste des processus : le chemin complet de la JVM avec laquelle il a démarré y figure :

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

Si vous y voyez /usr/lib/jvm/java-21-openjdk-amd64/bin/java, l'affaire est réglée. Si vous voyez un simple java, votre service est accroché au lien symbolique des alternatives et suit ses changements. Pour un service en production, c'est la moins bonne des deux variantes.

Si vous montez de toute façon un serveur tout neuf, un coup d'œil préalable à notre check-list pour un nouveau serveur root vaut le détour : Java se place à la fin de cette liste, pas au début, car le dépannage d'une JVM ne devient supportable qu'avec un accès SSH fonctionnel, un pare-feu en place et un fuseau horaire correct.

En résumé

Java 21 est aujourd'hui la réponse par défaut, Java 25 la réponse tournée vers l'avenir, Java 17 celle qui s'éteint, et Java 8 comme Java 11 sont des dettes de migration. L'essentiel n'est toutefois pas le chiffre seul, mais la combinaison entre l'application et la distribution : Debian 12 ne vous donne que 17, Debian 13 seulement 21 et 25, Ubuntu vous donne tout. Là où le paquet manque, Temurin comble le trou. Et dès que plus d'une version se trouve sur la machine, la règle est simple : update-alternatives --set plutôt que l'automatisme, et dans les unités systemd, mieux vaut d'emblée le chemin absolu.