Java verwijderen op de Mac: JDK's, JRE-resten, PATH

In "Java verwijderen op de Mac" zitten twee vragen verstopt, en het verkeerde antwoord is hoe mensen met een kapotte toolchain eindigen. De eerste is welke Java je hebt. De tweede is wat er verder op de machine verwacht dat die er nog is.

De eigen instructies van Oracle zijn kort, en de belangrijkste regel daarin is geen stap. Het is een waarschuwing over een map die je met rust moet laten.

Voer voordat je een bestand aanraakt /usr/libexec/java_home -V uit. Dat maakt van een vage Java-installatie een lijst van echte JDK's en paden, zodat je één versie kunt verwijderen via dezelfde pakketbeheerder of hetzelfde installatieprogramma dat hem heeft geplaatst. De opdrachten onder /usr/bin zijn systeemstubs, niet de runtime die je zoekt.

Haal Java niet weg uit /usr/bin

De huidige installatiegids van Oracle voor de JDK op macOS zegt het direct: probeer Java niet te verwijderen door de Java-tools uit /usr/bin te halen. Die map hoort bij de systeemsoftware, en elke wijziging wordt door Apple teruggezet bij de volgende macOS-update.

Dit is de meest voorkomende manier waarop de klus misgaat. which java geeft een pad onder /usr/bin terug, en dat lijkt het antwoord, maar dat is het niet. Op macOS zijn dat stubs die wijzen naar de runtime die echt geïnstalleerd is. Ze verwijderen haalt de wegwijzers weg, niet het gebouw, en macOS zet ze later toch terug.

Weet welke Java je verwijdert

Een runtime en een ontwikkelkit zijn verschillende installaties met verschillende verwijderingen.

De Oracle JRE, de consumentenruntime met de browserplug-in en het voorkeurenpaneel, staat op drie plekken die Oracle noemt:

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

Een JDK staat apart, installeert onder /Library/Java/JavaVirtualMachines/, en verwijderen vraagt beheerdersrechten. Je kunt er meerdere naast elkaar hebben, en dat is normaal en vaak bewust.

Zet op een rij wat er echt geïnstalleerd is voordat je beslist:

/usr/libexec/java_home -V

Dit toont elke JDK die het systeem kent, met versie en pad. Heeft die lijst één regel, dan is de keuze eenvoudig. Heeft hij er vier, dan telt de volgende sectie.

De verkeerde JDK verwijderen breekt andere software

Java wordt zelden voor zichzelf geïnstalleerd. Android-tooling, Elasticsearch, Minecraft-launchers, JetBrains-IDE's, Apache-tooling en diverse zakelijke vpn- en afdrukclients leveren een JVM mee of hangen ervan af. Sommige bundelen hun eigen kopie en merken niets. Andere pakken wat het systeem aanbiedt en stoppen met werken als dat verandert.

Is een JDK door een pakketbeheerder geïnstalleerd, verwijder hem dan op dezelfde manier als hij kwam. Een via Homebrew geïnstalleerde Temurin gaat eruit met brew uninstall, en de bestanden met de hand wegtrekken laat de pakketdatabase beweren dat hij er nog is.

Verwijder een JDK op de ondersteunde manier

Voor een Oracle JDK uit een .pkg is het gedocumenteerde verwijderdoel van Oracle de bijpassende map onder /Library/Java/JavaVirtualMachines/ die de versie in de naam draagt, en die heeft sudo nodig. Verwijder één versie per keer en controleer de tools die voor jou tellen voordat je de volgende weghaalt.

Daarna mag /usr/libexec/java_home -V hem niet meer noemen, en elke JAVA_HOME die je met de hand in een shellprofiel hebt gezet, wijst nu naar niets. Die variabele is de op een na meest voorkomende oorzaak van een toolchain die na een schone verwijdering faalt.

Controleer voordat je de terminal sluit

/usr/libexec/java_home -V
java -version

De eerste toont wat er overblijft. De tweede meldt een versie, of zegt dat er geen runtime geïnstalleerd is. Op een machine die je wilde leegmaken, is dat het juiste antwoord en geen fout.

Waar een voetafdruk helpt

De resten van Java zijn klein, verspreid en saai: caches, voorkeuren, een plug-in, een voorkeurenpaneel. Het interessante deel is de inventaris, en de terminal geeft je die al. Wil je liever de hele voetafdruk van een JDK zien, of van de apps die er een bundelen, in één lijst met groottes, dan doet Mole dat zonder dat je de paden van tevoren hoeft te kennen.

Drie plekken om daarna te controleren

De eerste is je shellprofiel. Een met de hand geschreven JAVA_HOME in ~/.zshrc of ~/.zprofile vertrekt niet met de JDK. Hij blijft wijzen naar een pad dat niet meer bestaat, en elke nieuwe shell erft de kapotte variabele. Haal de regel weg, of verander hem in export JAVA_HOME=$(/usr/libexec/java_home) zodat hij volgt wat het systeem heeft.

De tweede zijn je IDE's. JetBrains-tools en Android Studio onthouden een specifiek JDK-pad per project en volgen een systeemwijziging niet. Dat zie je als één project niet bouwt terwijl de opdrachtregel in orde is.

De derde is alles wat een pakketbeheerder heeft geïnstalleerd. brew list | grep -i -E 'jdk|temurin|zulu|openjdk' toont wat van Homebrew kwam. Die gaan eruit met brew uninstall. Hun mappen met de hand verwijderen laat de pakketdatabase denken dat ze nog geïnstalleerd zijn.