Quitar Java de un Mac sin romper las herramientas de desarrollo

Dentro de «desinstalar Java en Mac» hay dos preguntas, y responder a la equivocada es lo que deja a la gente con una cadena de herramientas rota. La primera es qué Java tienes. La segunda es qué más en la máquina espera que esté ahí.

Las instrucciones de Oracle son breves, y la línea más importante no es un paso. Es una advertencia sobre un directorio que debes dejar en paz.

No quites Java de /usr/bin

Oracle lo dice directamente: no intentes desinstalar Java eliminando las herramientas de Java de /usr/bin. Ese directorio forma parte del software del sistema, y Apple restablece cualquier cambio la próxima vez que se actualice macOS.

Esta es la forma más habitual de que la tarea salga mal. Escribir which java devuelve una ruta bajo /usr/bin, que parece la respuesta, y no lo es. En macOS esos son stubs que apuntan al runtime realmente instalado. Borrarlos quita los accesos, no la instalación, y macOS los restaura más tarde de todos modos.

Identifica qué Java estás quitando

Un runtime y un kit de desarrollo son instalaciones distintas con desinstalaciones distintas.

El JRE de Oracle, el runtime para el usuario con el complemento del navegador y el panel de preferencias, está en tres lugares que Oracle indica:

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

Un JDK va por separado, se instala bajo /Library/Java/JavaVirtualMachines/, y quitarlo requiere privilegios de administrador. Puedes tener varios en paralelo, lo cual es normal y a menudo deliberado.

Enumera lo que hay instalado de verdad antes de decidir:

/usr/libexec/java_home -V

Esto imprime cada JDK que el sistema conoce, con su versión y ruta. Si esa lista tiene una entrada, la elección es simple. Si tiene cuatro, la sección siguiente es la que importa.

Quitar el JDK equivocado rompe otro software

Java rara vez se instala por sí mismo. Las herramientas de Android, Elasticsearch, lanzadores de Minecraft, IDEs de JetBrains, herramientas de Apache y varios clientes empresariales de VPN e impresión se envían con o dependen de una JVM. Algunos incluyen su propia copia y no se ven afectados. Otros resuelven lo que ofrezca el sistema y dejan de funcionar cuando cambia.

Si un JDK lo instaló un gestor de paquetes, quítalo de la misma forma en que llegó. Un temurin instalado con Homebrew se desinstala con brew uninstall, y borrar sus archivos a mano deja la base de datos del paquete creyendo que sigue instalado.

Quita un JDK de la forma recomendada

Para un JDK que instalaste desde un .pkg, la eliminación consiste en borrar el directorio bajo /Library/Java/JavaVirtualMachines/ cuyo nombre lleva la versión, y necesita sudo. Quita una versión cada vez y comprueba las herramientas que te importan antes de quitar la siguiente.

Después, /usr/libexec/java_home -V ya no debería listarlo, y cualquier JAVA_HOME que hayas definido a mano en un perfil de shell queda apuntando a una ruta inexistente. Esa variable es la segunda causa más habitual de una cadena de herramientas que falla tras una eliminación limpia.

Comprueba antes de cerrar el terminal

/usr/libexec/java_home -V
java -version

El primero muestra lo que queda. El segundo o bien informa una versión o te dice que no hay runtime instalado, que en una máquina que querías limpiar es la respuesta correcta y no un error.

Dónde ayuda ver el rastro

Los restos de Java son pequeños, dispersos y poco interesantes: cachés, preferencias, un complemento, un panel de preferencias. La parte interesante es el inventario, y el terminal ya te lo da. Si prefieres ver en una sola lista con tamaños todo el rastro de un JDK o de las apps que incluyen uno, Mole lo hace sin pedirte que conozcas las rutas de antemano.

Tres sitios que conviene revisar después

El primero es el perfil del shell. Un JAVA_HOME escrito a mano en ~/.zshrc o ~/.zprofile no se elimina junto con el JDK. Sigue apuntando a una ruta que ya no existe, y cada shell nuevo hereda la variable rota. Elimina la línea, o cámbiala por export JAVA_HOME=$(/usr/libexec/java_home) para que use lo que tenga el sistema.

El segundo son tus IDE. Las herramientas de JetBrains y Android Studio registran una ruta concreta de JDK por proyecto y no siguen un cambio del sistema, lo que se manifiesta como un proyecto que no compila mientras la línea de comandos funciona bien.

El tercero es cualquier cosa instalada por un gestor de paquetes. brew list | grep -i -E 'jdk|temurin|zulu|openjdk' muestra lo que vino de Homebrew. Esos se desinstalan con brew uninstall; borrar sus directorios a mano deja la base de datos de paquetes creyendo que siguen instalados.