Installer le JDK 11 et vérifier l’installation

Vous êtes seul devant votre machine, et c’est ici que le parcours peut s’arrêter avant d’avoir commencé. Pas sur les boucles, pas sur Selenium : sur l’installation. Une commande qui répond « n’est pas reconnu », une version qui n’est pas la bonne, un javac introuvable, et la motivation part.

Ce chapitre existe pour que cela ne vous arrive pas. Il est long parce qu’il couvre les trois systèmes et les pannes courantes. Vous n’en lirez qu’un tiers : celui qui correspond à votre machine, plus la section de vérification, qui est commune à tout le monde.

Comptez 20 minutes : 5 de lecture, 10 d’installation, 5 de vérification.

Le critère de réussite

Avant de commencer, sachez exactement où vous devez arriver. À la fin de ce chapitre, dans un terminal neuf, ces deux commandes doivent répondre :

java -version
javac -version

Et les deux doivent afficher une version qui commence par 11.. Par exemple :

openjdk version "11.0.28" 2025-07-15
OpenJDK Runtime Environment (build 11.0.28+6-post-Ubuntu-1ubuntu122.04.1)
OpenJDK 64-Bit Server VM (build 11.0.28+6-post-Ubuntu-1ubuntu122.04.1, mixed mode, sharing)

javac 11.0.28

Les deuxième et troisième lignes varient selon la distribution que vous avez installée : elles mentionnent « Temurin » si vous avez pris Temurin, le nom de votre distribution Linux si vous avez pris son paquet. Le numéro après 11. (ici .0.28) dépend de la date à laquelle vous installez. Ni l’un ni l’autre n’a d’importance. Ce qui compte, c’est le 11 de tête, et le fait que les deux commandes répondent.

Si java répond et que javac ne répond pas, vous n’avez pas terminé. C’est le piège classique de ce chapitre, et la section suivante explique pourquoi.

Ce que ce chapitre ne couvre pas

Pour que vous sachiez à quoi vous en tenir :

• Il n’installe pas Maven, ni VS Code, ni les navigateurs, ni Selenium. Chacun a son chapitre.
• Il ne traite pas des JDK 8, 17 ou 21 comme version de travail du parcours. Tout le parcours est écrit et exécuté sur Java 11. Si vous avez déjà un autre JDK sur votre machine, gardez-le : la dernière section montre comment les faire cohabiter.
• Il ne traite pas des environnements Docker, WSL2 ou machines virtuelles. Si vous travaillez dans WSL2, appliquez la procédure Linux à l’intérieur de WSL2, et vérifiez-la depuis le terminal WSL2, pas depuis PowerShell.
• Il ne vous apprend pas à écrire du Java. Le petit programme de contrôle en fin de chapitre sert uniquement de preuve que la chaîne compilation + exécution fonctionne.

Pourquoi un JDK, et pas seulement « Java »

Le mot « Java » recouvre trois choses différentes, et les confondre coûte cher.

Un utilisateur qui lance une application Java n’a besoin que du JRE. Vous, vous allez écrire du code : il vous faut le JDK.

Le piège est là. Une machine peut avoir déjà « Java » installé, hérité d’une autre application : souvent un JRE seul. Résultat : java -version répond parfaitement, vous vous croyez prêt, et deux chapitres plus loin Maven vous jette avec un message obscur parce qu’il n’y a pas de compilateur.

D’où la règle : javac -version est le seul vrai test. Si javac répond en 11, vous avez un JDK 11.

Quelle distribution installer

Java est une spécification ; plusieurs organisations en publient une implémentation. Pour ce parcours, nous utilisons Eclipse Temurin, les binaires produits par le projet Adoptium de la Fondation Eclipse. C’est un choix défendable pour trois raisons concrètes :

• c’est gratuit, sans compte à créer et sans conditions d’utilisation à éplucher ;
• il existe des binaires pour Windows, macOS Intel, macOS Apple Silicon et Linux ;
• Java 11 y est publié comme version LTS (support à long terme).

Page de téléchargement : https://adoptium.net/temurin/releases/ — filtrez sur Version 11 (LTS) et sur votre système.

Ce n’est pas la seule option valable. Microsoft Build of OpenJDK, Amazon Corretto, Azul Zulu, ou simplement le paquet openjdk-11-jdk de votre distribution Linux conviennent tout aussi bien. Rien dans ce parcours ne dépend d’une distribution particulière : il faut un JDK 11, point. Si votre entreprise impose déjà un JDK 11 sur votre poste, utilisez-le et passez directement à la section de vérification.

Étape 0 — Regarder ce qui est déjà installé

Avant d’installer quoi que ce soit, ouvrez un terminal et regardez ce que la machine a déjà. Cela vous évitera peut-être l’installation, et surtout cela vous dira à quel problème vous avez affaire.

Ouvrir un terminal :

Puis, quel que soit le système :

java -version
javac -version

Trois cas :

1. Les deux répondent en 11.x — vous avez déjà ce qu’il faut. Sautez à « La vérification qui fait foi » pour confirmer, puis passez au chapitre suivant.
2. Rien ne répond (« n’est pas reconnu », « command not found ») — rien n’est installé, ou rien n’est dans le PATH. Suivez la procédure de votre système ci-dessous.
3. java répond mais pas javac, ou une version autre que 11 — lisez quand même la procédure de votre système, puis la section « Quand ça rate », qui traite précisément ces deux cas.

Un détail qui surprend : java -version écrit sa réponse sur la sortie d’erreur, pas sur la sortie standard. C’est normal, ce n’est pas un bug. Cela n’a de conséquence que si vous redirigez la sortie dans un fichier : java -version > fichier.txt produit un fichier vide. Pour capturer la réponse, il faut écrire java -version > fichier.txt 2>&1, dans cet ordre. javac -version, lui, écrit bien sur la sortie standard.

Installer sur Windows

Le chemin normal, avec droits administrateur

1. Allez sur https://adoptium.net/temurin/releases/.

2. Choisissez Operating System : Windows, Architecture : x64, Package Type : JDK, Version : 11.

3. Téléchargez le fichier .msi (pas le .zip, sauf si vous n’avez pas les droits administrateur — voir plus bas).

4. Lancez le .msi. Acceptez la licence, laissez le dossier d’installation proposé.

5. Arrêtez-vous sur l’écran « Custom Setup ». C’est l’écran qui décide si tout le reste va marcher. Quatre entrées y figurent, chacune avec une icône de disque dur :

   • Add to PATH — doit être activée ;
   • Set JAVA_HOME variable — doit être activée ;
   • Associate .jar — sans importance ;
   • JavaSoft (Oracle) registry keys — sans importance.

   Selon la version de l’installateur, Set JAVA_HOME variable est parfois désactivée par défaut, signalée par une croix rouge. Cliquez sur son icône et choisissez « Will be installed on local hard drive ». Faites de même pour Add to PATH si elle porte une croix.

6. Terminez l’installation.

7. Fermez complètement votre terminal et rouvrez-en un neuf. Un terminal déjà ouvert garde l’ancien PATH en mémoire : vos commandes échoueront alors que tout est correct. Si vous avez un VS Code ouvert, fermez-le aussi et rouvrez-le.

Le dossier d’installation ressemble à :

C:\Program Files\Eclipse Adoptium\jdk-11.0.28.6-hotspot

Vérifiez dans PowerShell :

java -version
javac -version
echo $env:JAVA_HOME
where.exe java

echo $env:JAVA_HOME doit afficher le dossier du JDK, sans \bin à la fin. C’est une erreur classique : JAVA_HOME désigne la racine du JDK, c’est le PATH qui contient le \bin.

Poser JAVA_HOME et le PATH à la main

Si l’installateur ne les a pas posés, ou si vous avez extrait une archive .zip :

1. Touche Windows, tapez variables d’environnement, ouvrez « Modifier les variables d’environnement système ».
2. Bouton « Variables d’environnement… ».
3. Dans le cadre du bas (variables système) ou du haut (variables utilisateur, si vous n’êtes pas administrateur) : Nouvelle…
   • Nom : JAVA_HOME
   • Valeur : C:\Program Files\Eclipse Adoptium\jdk-11.0.28.6-hotspot (adaptez au numéro réel de votre dossier)
4. Sélectionnez la variable Path, Modifier…, Nouveau, et ajoutez :
   • %JAVA_HOME%\bin
5. Faites-la remonter tout en haut de la liste avec le bouton « Monter ». L’ordre compte : Windows prend le premier java.exe qu’il trouve dans le PATH.
6. OK, OK, OK. Fermez et rouvrez le terminal.

Trois pièges dans cette fenêtre :

• Ne mettez pas de guillemets autour de la valeur, même si le chemin contient des espaces. La boîte de dialogue s’en charge.
• Pas de barre oblique inverse finale. ...\jdk-11.0.28.6-hotspot\ casse la concaténation %JAVA_HOME%\bin.
• N’utilisez pas setx PATH "%PATH%;..." en ligne de commande. Cette commande tronque la valeur au-delà d’une certaine longueur et fusionne PATH système et PATH utilisateur : vous pouvez perdre une partie de votre PATH de façon durable. Passez par la fenêtre graphique. setx JAVA_HOME "..." seul, en revanche, est sans danger :

setx JAVA_HOME "C:\Program Files\Eclipse Adoptium\jdk-11.0.28.6-hotspot"

Sans droits administrateur — poste d’entreprise

Cette situation a une solution propre : le JDK n’a pas besoin d’être installé, il suffit qu’il soit posé quelque part et que le PATH le trouve.

1. Sur la page Adoptium, téléchargez le .zip au lieu du .msi.
2. Extrayez-le dans un dossier où vous écrivez sans droits particuliers, par exemple :

   C:\Users\VotreNom\jdk-11
   

Après extraction vous devez avoir C:\Users\VotreNom\jdk-11\bin\javac.exe. Si le .zip a créé un dossier intermédiaire (jdk-11.0.28+6), c’est ce dossier-là qui est votre JAVA_HOME. 3. Touche Windows, tapez variables d’environnement, et ouvrez cette fois « Modifier les variables d’environnement pour votre compte ». Attention : ce n’est pas la même entrée que « Modifier les variables d’environnement système », qui passe par les propriétés système et déclenche une demande d’élévation sur un poste verrouillé. L’entrée « pour votre compte » s’ouvre sans droits administrateur et ne montre que vos variables utilisateur — c’est suffisant. 4. Créez JAVA_HOME avec le chemin de votre dossier, et ajoutez %JAVA_HOME%\bin au Path utilisateur. 5. Fermez et rouvrez le terminal.

Si même cette fenêtre est bloquée par votre politique d’entreprise, vous pouvez encore travailler en posant les variables au début de chaque session PowerShell :

$env:JAVA_HOME = "C:\Users\VotreNom\jdk-11"
$env:Path = "$env:JAVA_HOME\bin;" + $env:Path
java -version

Ces deux lignes ne durent que le temps de la fenêtre. C’est une solution de dépannage, pas une installation : vous devrez les retaper à chaque ouverture. Si vous en arrivez là, demandez une élévation de droits ponctuelle à votre service informatique, ou installez sur une machine personnelle.

Installer sur macOS

Intel ou Apple Silicon : choisir le bon fichier

Cette étape d’abord, car se tromper de fichier est la principale cause d’ennuis sur Mac. Dans un terminal :

uname -m

Un JDK x64 s’exécute sur Apple Silicon via Rosetta 2, mais il est plus lent et produit des messages déroutants quand une bibliothèque native s’en mêle. Prenez aarch64 si uname -m répond arm64.

Installation par le paquet officiel

1. Sur https://adoptium.net/temurin/releases/, choisissez macOS, l’architecture identifiée ci-dessus, Package Type : JDK, Version : 11.
2. Téléchargez le .pkg et lancez-le.
3. Si macOS refuse d’ouvrir le fichier, faites un clic droit sur le .pkg puis Ouvrir, et confirmez. Vous pouvez aussi autoriser l’ouverture dans Réglages Système → Confidentialité et sécurité (sur les macOS antérieurs à Ventura : Préférences Système → Sécurité et confidentialité), où un bouton « Ouvrir quand même » apparaît juste après le refus.
4. Le JDK atterrit dans :

openjdk version "11.0.28" 2025-07-15
OpenJDK Runtime Environment (build 11.0.28+6-post-Ubuntu-1ubuntu122.04.1)
OpenJDK 64-Bit Server VM (build 11.0.28+6-post-Ubuntu-1ubuntu122.04.1, mixed mode, sharing)

0

Installation par Homebrew

Si vous utilisez déjà Homebrew :

brew install --cask temurin@11

Si Homebrew répond que ce cask n’existe pas, le nom a changé selon les versions ; essayez alors :

brew install --cask temurin11

Déclarer JAVA_HOME

macOS fournit un utilitaire qui liste les JDK installés et donne leur chemin :

/usr/libexec/java_home -V

Il affiche la liste des JDK trouvés. Pour obtenir le chemin du JDK 11 précisément :

/usr/libexec/java_home -v 11

S’il répond un chemin, tout est en place. S’il répond :

Unable to find any JVMs matching version "11".

c’est qu’aucun JDK 11 n’est enregistré : l’installation n’a pas abouti, ou vous avez installé une autre version. Reprenez l’installation avant d’aller plus loin — sinon les deux lignes ci-dessous écriraient dans votre configuration un JAVA_HOME qui restera vide à chaque ouverture de terminal.

Ajoutez maintenant JAVA_HOME à votre shell. Depuis macOS Catalina, le shell par défaut est zsh et le fichier est ~/.zshrc :

echo 'export JAVA_HOME=$(/usr/libexec/java_home -v 11)' >> ~/.zshrc
echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.zshrc
source ~/.zshrc

Attention aux guillemets : ce sont des apostrophes simples ' autour du texte passé à echo. Elles empêchent le shell d’évaluer $JAVA_HOME maintenant ; on veut écrire le texte tel quel dans le fichier, pour qu’il soit évalué à chaque ouverture de terminal.

Si vous utilisez encore bash, remplacez ~/.zshrc par ~/.bash_profile dans les trois lignes. Pour savoir lequel :

echo $SHELL

Puis fermez le terminal, rouvrez-en un, et vérifiez :

echo $JAVA_HOME
java -version
javac -version

Installer sur Linux

Debian, Ubuntu, Mint, Pop!_OS

sudo apt update
sudo apt install -y openjdk-11-jdk

Le nom du paquet est openjdk-11-jdk, pas openjdk-11-jre. Le second n’installe pas javac.

Fedora, RHEL, Rocky, AlmaLinux

javac 11.0.28

0

Le suffixe -devel est obligatoire : sans lui, vous obtenez le runtime seul et javac reste introuvable.

Arch, Manjaro

sudo pacman -S jdk11-openjdk

openSUSE

sudo zypper install java-11-openjdk-devel

Si le paquet n’existe pas dans vos dépôts

Java 11 n’est plus proposé par toutes les versions de distribution. Si votre gestionnaire de paquets répond E: Impossible de trouver le paquet openjdk-11-jdk (E: Unable to locate package…), ou l’équivalent chez dnf, ce n’est pas une faute de frappe de votre part. Vérifiez ce qui est réellement disponible :

apt-cache search openjdk-11

dnf search openjdk

pacman -Ss openjdk

Si Java 11 n’y figure pas, n’essayez pas de forcer : passez par l’archive .tar.gz de Temurin, décrite juste en dessous. La procédure est écrite pour un compte sans droits root, mais elle fonctionne aussi bien si vous les avez — dans ce cas vous pouvez extraire dans /opt plutôt que dans votre dossier personnel.

Sans droits root

Téléchargez l’archive .tar.gz de Temurin (Linux, x64 ou aarch64 selon uname -m), puis, en remplaçant le nom de fichier par celui que vous avez réellement téléchargé :

mkdir -p ~/.local/java
tar -xzf OpenJDK11U-jdk_x64_linux_hotspot_11.0.28_6.tar.gz -C ~/.local/java
ls ~/.local/java

ls vous donne le nom exact du dossier extrait, par exemple jdk-11.0.28+6. Reprenez ce nom dans les deux lignes suivantes :

echo 'export JAVA_HOME=$HOME/.local/java/jdk-11.0.28+6' >> ~/.bashrc
echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

Déclarer JAVA_HOME après une installation par paquet

Les paquets de distribution posent java et javac dans le PATH, mais pas JAVA_HOME. Maven en aura besoin. Le chemin dépend de la distribution ; plutôt que de le deviner, demandez-le au système :

dirname "$(dirname "$(readlink -f "$(which javac)")")"

Cette commande remonte du lien symbolique /usr/bin/javac jusqu’au binaire réel, puis de deux niveaux (bin, puis la racine du JDK). Sur Debian et Ubuntu, elle répond typiquement :

/usr/lib/jvm/java-11-openjdk-amd64

Attention : elle vous donne le JDK actuellement actif, pas forcément le 11. Si elle répond java-17-openjdk-amd64, arbitrez d’abord (section « Quand ça rate »), puis relancez-la.

Reportez ce résultat dans votre ~/.bashrc (ou ~/.zshrc si vous utilisez zsh) :

java -version
javac -version

0

Si plusieurs JDK sont installés, il faut choisir celui qui répond. Sur Debian, Ubuntu et dérivées :

sudo update-alternatives --config java
sudo update-alternatives --config javac

Faites bien les deux : java et javac ont des alternatives distinctes, et il est tout à fait possible d’avoir java en 11 et javac en 17. Sur Fedora et dérivées, la commande s’appelle alternatives ; sur Arch et Manjaro, c’est archlinux-java. Les deux sont détaillées plus bas.

La vérification qui fait foi

Fermez tous vos terminaux. Ouvrez-en un neuf. C’est important : c’est le seul moyen de tester la configuration telle qu’elle sera demain matin, et pas telle que votre session en cours l’a gardée en mémoire.

Les trois commandes

java -version
javac -version

Puis, pour JAVA_HOME :

echo $JAVA_HOME

sur macOS et Linux, ou en PowerShell :

echo $env:JAVA_HOME

Ce que vous devez voir :

Notez le piège de lecture : Java 8 s’affiche 1.8.0_412. Le 1. de tête est un héritage de l’ancienne numérotation. Java 11 s’affiche 11.0.x, jamais 1.11. Si vous voyez 1.8, vous êtes sur Java 8.

Le test qui prouve la chaîne complète

Les commandes -version prouvent que les binaires existent. Elles ne prouvent pas que vous pouvez compiler puis exécuter. Faisons-le.

Créez un dossier de travail :

mkdir -p ~/verif-jdk
cd ~/verif-jdk

Sur Windows, en PowerShell :

mkdir $HOME\verif-jdk
cd $HOME\verif-jdk

Dans ce dossier, créez un fichier nommé exactement VerifJdk.java (respectez les majuscules : le nom du fichier doit correspondre au nom de la classe). VS Code n’est pas encore installé — c’est le chapitre suivant — mais votre système fournit déjà un éditeur. Sur Windows :

notepad VerifJdk.java

Le Bloc-notes propose de créer le fichier : acceptez, collez le code, puis Ctrl+S. Sur macOS et Linux :

nano VerifJdk.java

Collez le code, puis Ctrl+O, Entrée, Ctrl+X. Dans les deux cas, le contenu est celui-ci :

public class VerifJdk {
    public static void main(String[] args) {
        System.out.println("Version Java : " + System.getProperty("java.version"));
        System.out.println("Repertoire du JDK : " + System.getProperty("java.home"));
        System.out.println("Le JDK est operationnel.");
    }
}

Compilez, puis exécutez :

C:\Program Files\Eclipse Adoptium\jdk-11.0.28.6-hotspot

0

La première commande n’affiche rien si elle réussit — c’est normal, javac est silencieux en cas de succès. Elle crée un fichier VerifJdk.class à côté du .java. La seconde doit afficher trois lignes de ce genre :

Version Java : 11.0.28
Repertoire du JDK : /usr/lib/jvm/java-11-openjdk-amd64
Le JDK est operationnel.

Le chemin affiché dépend de votre système et de votre distribution. Ce qui compte : la première ligne commence par 11., et les trois lignes s’affichent.

Notez au passage que java ne prend pas l’extension : c’est java VerifJdk, pas java VerifJdk.class. C’est un nom de classe, pas un nom de fichier. (Depuis Java 11, java VerifJdk.java fonctionne aussi et compile à la volée — mais gardez les deux étapes séparées, c’est ce que vous ferez partout ailleurs.)

Si ces trois lignes s’affichent avec un 11. en tête, ce chapitre est terminé. Vous pouvez supprimer le dossier verif-jdk.

Si la compilation ou l’exécution échoue

Trois messages reviennent. Les voici tels qu’ils s’affichent, avec leur cause.

VerifJdk.java:1: error: class VerifJdk is public, should be declared in a file named VerifJdk.java
public class VerifJdk {
       ^
1 error

Le nom du fichier ne correspond pas au nom de la classe, à la casse près. verifjdk.java ou VerifJDK.java ne passent pas. Renommez le fichier en VerifJdk.java, exactement.

Erreur : impossible de trouver ou de charger la classe principale VerifJdk
Causé par : java.lang.ClassNotFoundException: VerifJdk

En anglais : Error: Could not find or load main class VerifJdk. Vous n’êtes pas dans le dossier qui contient VerifJdk.class, ou vous avez tapé java VerifJdk.class au lieu de java VerifJdk. Vérifiez avec ls (dir sur Windows) que VerifJdk.class est bien là où vous êtes.

Erreur : LinkageError lors du chargement de la classe principale VerifJdk
	java.lang.UnsupportedClassVersionError: VerifJdk has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

Celui-ci est le plus instructif : votre javac et votre java ne sont pas la même version. 55.0 correspond à Java 11, 61.0 à Java 17. Ici, un javac 17 a compilé, et un java 11 a refusé de charger le résultat. C’est exactement la configuration bancale que ce chapitre cherche à éliminer : reprenez la section « java répond en 8, 17 ou 21 » ci-dessous, puis recompilez.

Quand ça rate

« java n’est pas reconnu » / « command not found »

Le binaire existe peut-être, mais le terminal ne sait pas où le chercher. Trois causes, à examiner dans cet ordre :

1. Vous n’avez pas rouvert le terminal. Un terminal ouvert avant l’installation garde l’ancien PATH. Fermez-le entièrement — pas seulement l’onglet — et rouvrez-en un. Sur Windows, fermez aussi VS Code.
2. Le PATH ne contient pas le bin du JDK. Regardez ce que le système trouve :

   which java
   which javac
   

   where.exe java
   where.exe javac
   

Si which javac ne répond rien, reprenez la section « Déclarer JAVA_HOME » de votre système. 3. L’installation a échoué sans le dire. Allez voir le dossier d’installation. Le fichier bin/javac (bin\javac.exe sur Windows) doit exister. S’il n’y est pas, réinstallez.

java répond, javac non

C’est le piège annoncé en début de chapitre : vous avez un JRE, pas un JDK. Ou bien vous avez les deux, et le JRE passe en premier dans le PATH.

Sur Windows, commencez par regarder quel java.exe gagne. Tapez :

where.exe java

Si la première ligne est C:\Program Files\Common Files\Oracle\Java\javapath\java.exe ou C:\ProgramData\Oracle\Java\javapath\java.exe, c’est un ancien JRE Oracle qui a placé son raccourci en tête du PATH. Il contient java.exe mais pas javac.exe. Solution : dans la fenêtre des variables d’environnement, faites remonter %JAVA_HOME%\bin au-dessus de cette ligne dans le Path, ou supprimez la ligne javapath si vous n’avez pas d’application qui en dépend.

Sur Linux, installez le paquet de développement (openjdk-11-jdk, java-11-openjdk-devel) et non le paquet runtime.

Sur macOS, vérifiez que vous avez bien téléchargé un JDK et pas un JRE : le sélecteur « Package Type » d’Adoptium propose les deux.

java répond en 8, 17 ou 21

Plusieurs JDK cohabitent, et ce n’est pas le bon qui gagne. Il n’y a rien à désinstaller ; il faut arbitrer.

• Debian, Ubuntu et dérivées :

  sudo update-alternatives --config java
  sudo update-alternatives --config javac
  

Choisissez la ligne java-11 dans les deux menus.

• Fedora, RHEL, Rocky, AlmaLinux : la commande s’appelle alternatives, sans le préfixe update- :

  sudo alternatives --config java
  sudo alternatives --config javac
  

• Arch, Manjaro : update-alternatives n’existe pas. L’outil est archlinux-java, et il bascule java et javac ensemble :

java -version
javac -version
echo $env:JAVA_HOME
where.exe java

0

• macOS :

  /usr/libexec/java_home -V
  

Vérifiez que la ligne 11 est présente, puis assurez-vous que votre ~/.zshrc contient bien export JAVA_HOME=$(/usr/libexec/java_home -v 11) et que $JAVA_HOME/bin est au début du PATH, pas à la fin.

• Windows : ouvrez la fenêtre des variables d’environnement et regardez l’ordre du Path. Le premier dossier contenant un java.exe gagne. Faites remonter %JAVA_HOME%\bin tout en haut, et corrigez JAVA_HOME s’il pointe vers un autre JDK.

Dans tous les cas, refermez et rouvrez le terminal avant de retester.

JAVA_HOME est vide, ou pointe ailleurs

Symptôme typique : java -version répond 11 correctement, mais Maven (au chapitre suivant) se plaint de JAVA_HOME. Les deux mécanismes sont indépendants : le PATH sert au terminal, JAVA_HOME sert aux outils qui veulent le dossier du JDK, pas seulement l’exécutable.

Vérifiez la cohérence avec ce test : le chemin donné par JAVA_HOME doit contenir bin/javac.

ls "$JAVA_HOME/bin/javac"

dir "$env:JAVA_HOME\bin\javac.exe"

Si la commande répond « fichier introuvable » alors que javac -version marche, votre JAVA_HOME désigne le mauvais dossier. Deux erreurs habituelles : il finit par \bin (il ne doit pas), ou il pointe vers un JRE.

Autre cas : JAVA_HOME est écrasé après votre définition. Cela arrive quand la variable est posée à deux endroits — par exemple dans les variables système et dans ~/.zshrc, ou deux fois dans le même ~/.bashrc parce que vous avez rejoué les commandes echo … >> ~/.bashrc. Ouvrez le fichier et regardez :

grep -n JAVA_HOME ~/.bashrc ~/.zshrc ~/.bash_profile 2>/dev/null

S’il y a plusieurs lignes, c’est la dernière qui gagne. Supprimez les doublons.

macOS : « Unable to locate a Java Runtime »

Message exact :

The operation couldn't be completed. Unable to locate a Java Runtime.

macOS fournit un java factice qui ne sert qu’à afficher ce message quand aucun JDK n’est installé. Ce n’est pas une erreur de PATH : il n’y a réellement rien. Installez Temurin comme décrit plus haut. Sur d’anciennes versions de macOS, une fenêtre s’ouvre et propose de « télécharger » Java : refusez, elle mène à une page obsolète.

Apple Silicon : un JDK x64 installé par erreur

Si uname -m répond arm64 mais que Java semble anormalement lent à démarrer, vérifiez ce que le JDK dit de lui-même :

java -XshowSettings:properties -version 2>&1 | grep os.arch

Attendu sur Apple Silicon : os.arch = aarch64. Si vous lisez x86_64, vous avez installé le paquet Intel. Ce n’est pas bloquant pour le parcours, mais reprenez l’installation avec le fichier aarch64 : vous éviterez des surprises plus tard, quand les navigateurs et leurs pilotes entreront en jeu.

Vous n’avez aucun droit sur la machine

Récapitulons les options, de la meilleure à la moins bonne :

1. Demander à votre service informatique l’installation d’un JDK 11, ou une élévation de droits ponctuelle. C’est une demande banale et justifiable.
2. Archive .zip (Windows) ou .tar.gz (Linux, macOS) extraite dans votre dossier personnel, avec JAVA_HOME et PATH posés dans vos variables utilisateur — pas besoin d’administrateur. C’est la procédure décrite plus haut pour chaque système ; elle fonctionne bien.
3. Variables posées à la main à chaque session. Dépannage seulement.
4. Faire le parcours sur une machine personnelle. Si votre poste professionnel bloque aussi les téléchargements, l’exécution de binaires non signés ou l’accès à Maven Central, vous vous heurterez au même mur à chaque chapitre. Autant le savoir maintenant.

Faire cohabiter plusieurs JDK

Vous avez peut-être déjà un JDK 17 ou 21 pour un autre projet. N’en désinstallez aucun. Il suffit de basculer.

Sur macOS et Linux, une fonction dans votre ~/.zshrc ou ~/.bashrc fait l’affaire. Sur macOS :

jdk11() {
  export JAVA_HOME=$(/usr/libexec/java_home -v 11)
  export PATH=$JAVA_HOME/bin:$PATH
  java -version
}

Sur Linux, avec le chemin obtenu plus haut :

jdk11() {
  export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
  export PATH=$JAVA_HOME/bin:$PATH
  java -version
}

Après source ~/.zshrc (ou ~/.bashrc), la commande jdk11 bascule la session courante sur Java 11 et vous affiche la version pour confirmation. Cela ne change rien pour les autres terminaux.

Sur Windows, faites la même chose au début de votre session PowerShell :

$env:JAVA_HOME = "C:\Program Files\Eclipse Adoptium\jdk-11.0.28.6-hotspot"
$env:Path = "$env:JAVA_HOME\bin;" + $env:Path
java -version

Une remarque honnête : le parcours est écrit, exécuté et corrigé sur Java 11. Un JDK plus récent fera probablement tourner la plupart des exemples, mais les sorties affichées dans les chapitres ne correspondront plus exactement aux vôtres, et certains messages d’erreur de Maven ou de Selenium changent d’une version à l’autre. Si vous voulez suivre sans friction, installez le 11.

Avant de passer au chapitre suivant

Votre installation est terminée quand ces cinq points sont vrais, dans un terminal ouvert après l’installation :

• [ ] java -version affiche une version commençant par 11.
• [ ] javac -version affiche javac 11.…
• [ ] echo $JAVA_HOME (ou echo $env:JAVA_HOME) affiche un chemin non vide, sans /bin ni \bin à la fin
• [ ] Ce chemin contient bien un fichier bin/javac
• [ ] javac VerifJdk.java puis java VerifJdk affichent les trois lignes attendues, la première commençant par Version Java : 11.

Si un seul de ces points est faux, ne passez pas à la suite. Le chapitre Maven part du principe que JAVA_HOME est correct, et une installation bancale ici produira au chapitre suivant des erreurs qui ne ressembleront en rien à un problème de JDK. C’est le genre de dette qui coûte une soirée.

Si vous êtes bloqué après avoir parcouru la section « Quand ça rate », notez pour vous : votre système et sa version, le résultat exact de java -version, de javac -version, de which java (ou where.exe java) et de echo $JAVA_HOME. Ce sont les cinq informations qu’on vous demandera de toute façon, et elles décrivent complètement l’état de votre installation.