Désinstaller Java sur un Mac sans casser la chaîne d'outils

Il y a deux questions cachées dans « désinstaller Java sur Mac », et c'est en répondant à la mauvaise qu'on se retrouve avec une chaîne d'outils cassée. La première est de savoir quel Java vous avez. La seconde est ce qui, sur la machine, compte encore sur sa présence.

Les instructions d'Oracle sont courtes, et la ligne la plus importante n'est pas une étape. C'est un avertissement au sujet d'un répertoire qu'il vaut mieux ne pas toucher.

Avant de supprimer les fichiers de support, consultez la procédure officielle actuelle d’Oracle JDK. Si l’éditeur fournit son propre programme ou une commande dans l’app, utilisez-le d’abord, puis ne traitez que les résidus dont le propriétaire est établi.

Ce document Oracle ne couvre que les JDK installés par le paquet .pkg d’Oracle, pas Temurin, Homebrew ni les runtimes intégrés aux apps.

Ne retirez pas Java de /usr/bin

Oracle le dit clairement : n'essayez pas de désinstaller Java en retirant les outils Java de /usr/bin. Ce répertoire fait partie du logiciel système, et toute modification est annulée par Apple à la prochaine mise à jour de macOS.

C'est l'erreur la plus fréquente. Taper which java renvoie un chemin sous /usr/bin, ce qui a l'air d'être la réponse, alors que ce n'en est pas une. Sur macOS ce sont des stubs qui pointent vers l'environnement d'exécution réellement installé. Les supprimer, c'est retirer les panneaux indicateurs, pas le bâtiment, et macOS les restaure de toute façon plus tard.

Sachez quel Java vous retirez

Un environnement d'exécution et un kit de développement sont des installations distinctes, qui se désinstallent différemment.

Le JRE Oracle, l'environnement d'exécution grand public avec le plug-in navigateur et le panneau de préférences, occupe trois emplacements nommés par Oracle :

/Library/Internet Plug-Ins/JavaAppletPlugin.plugin
/Library/PreferencePanes/JavaControlPanel.prefPane
~/Library/Application Support/Oracle/Java

Un JDK est distinct, s'installe sous /Library/Java/JavaVirtualMachines/, et le retirer nécessite des privilèges d'administrateur. Vous pouvez en avoir plusieurs côte à côte, ce qui est normal et souvent volontaire.

Listez ce qui est réellement installé avant de décider :

/usr/libexec/java_home -V

Cela affiche chaque JDK que le système connaît, avec sa version et son chemin. Si cette liste a une seule entrée, le choix est simple. Si elle en a quatre, la section suivante a son importance.

Retirer le mauvais JDK casse d'autres logiciels

Java est rarement installé pour lui seul. Les outils Android, Elasticsearch, les lanceurs Minecraft, les IDE JetBrains, les outils Apache, et plusieurs clients VPN et d'impression d'entreprise embarquent une JVM ou en dépendent. Certains embarquent leur propre copie et ne sont pas affectés. D'autres s'appuient sur ce que le système propose et cessent de fonctionner quand cela change.

Si un JDK a été installé par un gestionnaire de paquets, retirez-le de la même façon qu'il a été installé. Un temurin installé via Homebrew se désinstalle avec brew uninstall, et retirer ses fichiers à la main laisse la base de données des paquets croire qu'il est encore installé.

Retirez un JDK de la façon recommandée

Pour un JDK installé depuis un .pkg, la suppression consiste à retirer le répertoire sous /Library/Java/JavaVirtualMachines/ qui porte sa version dans le nom, et il faut sudo. Retirez une version à la fois et vérifiez les outils qui vous importent avant de retirer la suivante.

Ensuite, /usr/libexec/java_home -V ne devrait plus le lister, et toute JAVA_HOME que vous avez définie à la main dans un profil de shell ne pointe plus vers un chemin valide. Cette variable est la deuxième cause la plus courante d'une chaîne d'outils qui échoue après une suppression propre.

Vérifiez avant de fermer le Terminal

/usr/libexec/java_home -V
java -version

La première montre ce qui reste. La seconde rapporte une version ou vous dit qu'aucun environnement d'exécution n'est installé, ce qui, sur une machine que vous vouliez nettoyer, est le résultat attendu plutôt qu'une erreur.

Quand un inventaire des fichiers est utile

Les restes de Java sont petits, dispersés et peu intéressants : caches, préférences, un plug-in, un panneau de préférences. La partie intéressante est l'inventaire, et le Terminal vous le donne déjà. Si vous préférez voir toute l'empreinte d'un JDK ou des applications qui en embarquent un, dans une seule liste avec tailles, Mole le fait sans vous demander de connaître les chemins à l'avance.

Trois endroits à vérifier ensuite

Le premier est le profil de votre shell. Un JAVA_HOME saisi à la main dans ~/.zshrc ou ~/.zprofile ne disparaît pas avec le JDK. S’il désigne le JDK supprimé, chaque nouveau shell hérite du chemin invalide. Supprimez la ligne si vous n’avez plus besoin de JDK. S’il reste un JDK adapté, vérifiez son chemin ou utilisez export JAVA_HOME=$(/usr/libexec/java_home) puis contrôlez la version sélectionnée.

Le deuxième, ce sont vos IDE. Les outils JetBrains et Android Studio enregistrent un chemin de JDK spécifique par projet et ne suivent pas un changement système, ce qui se traduit par un projet qui ne compile plus alors que la ligne de commande fonctionne.

Le troisième, c'est tout ce qu'un gestionnaire de paquets a installé. brew list | grep -i -E 'jdk|temurin|zulu|openjdk' montre ce qui vient de Homebrew. Ces paquets se retirent avec brew uninstall ; les supprimer à la main laisse la base de données des paquets croire qu'ils sont encore installés.