# Desinstalar o Java no Mac: JDKs, restos de JRE e PATH > Remova instalações de JDK e JRE, limpe pastas Java restantes e corrija PATH ou JAVA_HOME sem quebrar apps que ainda precisam de um runtime. Published: 2026-08-08 | Updated: 2026-10-18 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](https://docs.oracle.com/en/java/javase/25/install/installation-jdk-macos.html) 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](https://mole.fit/) 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. --- Canonical HTML page: https://mole.fit/pt-br/blog/how-to-uninstall-java-mac Blog index for agents: https://mole.fit/pt-br/blog/llms.txt Site index for agents: https://mole.fit/llms.txt