Desinstalar o Java no Mac: JDKs, restos de JRE e PATH

DesinstalarPublicado Atualizado 5 min de leitura

Há duas perguntas escondidas em "desinstalar o Java no Mac", e responder a errada é como as pessoas acabam com uma toolchain quebrada. A primeira é qual Java você tem. A segunda é o que mais na máquina espera que ele esteja lá.

As instruções da própria Oracle são curtas, e a linha mais importante delas não é um passo. É um aviso sobre um diretório que você deve deixar quieto.

Antes de tocar em um arquivo, rode /usr/libexec/java_home -V. Ele transforma uma instalação vaga de Java numa lista de JDKs e caminhos reais, e assim você remove uma versão pelo mesmo gerenciador de pacotes ou instalador que a colocou lá. Os comandos em /usr/bin são atalhos do sistema, não o runtime que você procura.

Não remova o Java de /usr/bin

O guia atual da Oracle para instalar o JDK no macOS diz direto: não tente desinstalar o Java removendo as ferramentas Java de /usr/bin. Esse diretório faz parte do software do sistema, e qualquer mudança é desfeita pela Apple na próxima atualização do macOS.

Esse é o jeito mais comum de o trabalho dar errado. Digitar which java devolve um caminho em /usr/bin, que parece a resposta, e não é. No macOS esses são atalhos que apontam para o runtime que de fato está instalado. Apagá-los remove as placas, não o prédio, e o macOS as restaura depois de qualquer forma.

Saiba qual Java você está removendo

Um runtime e um kit de desenvolvimento são instalações diferentes, com remoções diferentes.

O JRE da Oracle, o runtime de consumo com o plug-in de navegador e o painel de preferências, fica em três lugares que a Oracle nomeia:

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

Um JDK é separado, instala em /Library/Java/JavaVirtualMachines/ e removê-lo exige privilégios de administrador. Você pode ter vários lado a lado, o que é normal e muitas vezes deliberado.

Atalhos de linha de comando nos diretórios do sistema apontam para JDKs instalados em Library Java Virtual Machines, enquanto o plug-in do runtime da Oracle e o painel de preferências são uma instalação separada.
Os comandos nos diretórios do sistema são ponteiros, não o runtime. Remover um JDK remove uma instalação real. Remover os ponteiros só quebra as placas, e o macOS as coloca de volta.

Liste o que está de fato instalado antes de decidir:

/usr/libexec/java_home -V

Isso imprime cada JDK que o sistema conhece, com versão e caminho. Se a lista tiver uma entrada, a escolha é simples. Se tiver quatro, a próxima seção importa.

Remover o JDK errado quebra outros programas

O Java raramente é instalado por ele mesmo. Ferramentas Android, Elasticsearch, launchers do Minecraft, IDEs da JetBrains, ferramentas Apache e vários clientes corporativos de VPN e impressão vêm com uma JVM ou dependem de uma. Alguns trazem a própria cópia e não são afetados. Outros resolvem o que o sistema oferece e param de funcionar quando isso muda.

Se um JDK foi instalado por um gerenciador de pacotes, remova-o do mesmo jeito que chegou. Um temurin instalado pelo Homebrew sai com brew uninstall, e puxar os arquivos à mão deixa o banco de pacotes afirmando que ele ainda está lá.

Remova um JDK do jeito suportado

Para um JDK da Oracle instalado a partir de um .pkg, o alvo de remoção documentado pela Oracle é o diretório correspondente em /Library/Java/JavaVirtualMachines/ que carrega a versão no nome, e ele precisa de sudo. Remova uma versão de cada vez e confira as ferramentas que importam para você antes de remover a próxima.

Depois, /usr/libexec/java_home -V não deve mais listá-lo, e qualquer JAVA_HOME que você definiu à mão num perfil de shell agora aponta para o nada. Essa variável é a segunda causa mais comum de uma toolchain que falha depois de uma remoção limpa.

Confira antes de fechar o Terminal

/usr/libexec/java_home -V
java -version

O primeiro mostra o que resta. O segundo ou informa uma versão ou diz que nenhum runtime está instalado, o que numa máquina que você queria limpar é a resposta correta, não um erro.

Onde uma visão da pegada ajuda

Os resíduos do Java são pequenos, espalhados e sem graça: caches, preferências, um plug-in, um painel de preferências. A parte interessante é o inventário, e o Terminal já dá isso. Se você prefere ver a pegada inteira de um JDK, ou dos apps que embutem um, numa única lista com tamanhos, o Mole faz isso sem pedir que você saiba os caminhos de antemão.

Três lugares para conferir depois

O primeiro é o perfil do shell. Um JAVA_HOME escrito à mão em ~/.zshrc ou ~/.zprofile não sai junto com o JDK. Ele continua apontando para um caminho que não existe mais, e todo shell novo herda a variável quebrada. Remova a linha, ou troque por export JAVA_HOME=$(/usr/libexec/java_home) para ela seguir o que o sistema tiver.

O segundo são as IDEs. Ferramentas da JetBrains e o Android Studio registram um caminho de JDK específico por projeto e não acompanham uma mudança do sistema, o que aparece como um projeto que não compila enquanto a linha de comando está bem.

O terceiro é qualquer coisa que um gerenciador de pacotes instalou. brew list | grep -i -E 'jdk|temurin|zulu|openjdk' mostra o que veio do Homebrew. Esses saem com brew uninstall. Apagar os diretórios à mão deixa o banco de pacotes acreditando que ainda estão instalados.