How to Remove Java From Mac Completely in 2026 (JDK, JRE & Old Versions)

If you need to uninstall Java on Mac — whether you're reclaiming disk space, switching JDK vendors, or just clearing out versions that accumulated over years of development — the process requires more than trashing one application. Java leaves files across multiple Library folders, system directories, and tool-specific caches. This guide covers every location for JDK, JRE, and legacy installs on both Apple Silicon (M1/M2/M3/M4) and Intel Macs running macOS Sequoia or Tahoe.

Why Java Leaves So Much Clutter

Unlike a typical Mac app that lives in /Applications, Java installs distribute files across your system. A single JDK version from Oracle or Adoptium can deposit binaries in /Library/Java/JavaVirtualMachines/, configuration in /Library/Application Support/Oracle/Java/, plugin shims under /Library/Internet Plug-Ins/, and cached class data in your user Library. Build tools like Maven and Gradle pile on their own caches. When you install multiple JDK versions over the years — say, Java 8, 11, 17, and 21 — the total footprint can exceed several gigabytes before you notice.

What's Taking Up Space: Java Folder Map

Before deleting anything, it helps to know exactly where Java puts things. The table below covers the main locations and their typical sizes.

How to Remove Java JDK Versions Completely (Step-by-Step)

Follow these steps in order. You'll need your administrator password for the system-level removals.

Step 1 — List installed JDKs

Open Terminal and run:

/usr/libexec/java_home -V

This prints every JDK registered with macOS and its path under /Library/Java/JavaVirtualMachines/. Note the folder names; you'll delete them individually.

Step 2 — Remove JDK bundles

Delete each JDK folder you want to remove. Replace jdk-21.jdk with the actual folder name from Step 1:

sudo rm -rf /Library/Java/JavaVirtualMachines/jdk-21.jdk

Repeat for each version. To remove all JDKs at once (use with caution):

sudo rm -rf /Library/Java/JavaVirtualMachines/*

Step 3 — Remove Oracle update infrastructure (if present)

These files are only present if you installed an Oracle JDK or JRE at some point:

sudo rm -rf "/Library/Application Support/Oracle/Java"
rm -rf "~/Library/Application Support/Oracle/Java"
rm -rf ~/Library/Caches/com.oracle.java.JavaUpdater

Also remove the legacy browser plugin if it exists:

sudo rm -rf /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin
sudo rm -rf /Library/PreferencePanes/JavaControlPanel.prefPane

Step 4 — Clean up preferences and launch agents

rm -f ~/Library/Preferences/com.oracle.java.JavaUpdater.plist
sudo rm -f /Library/LaunchAgents/com.oracle.java.JavaUpdateHelper.plist
sudo rm -f /Library/LaunchDaemons/com.oracle.java.Helper-Tool.plist
sudo rm -f /Library/PrivilegedHelperTools/com.oracle.java.JavaUpdateHelper

Step 5 — Verify Java is gone

After removing the JDK folders, running java -version in a new Terminal window should return command not found (or prompt you to install via the macOS developer tools dialog, which you can dismiss). If it still reports a version, check whether a JDK remains in /Library/Java/JavaVirtualMachines/ or whether a tool like SDKMAN, Homebrew, or jenv is managing its own copy.

Removing Java Installed via Homebrew or SDKMAN

Homebrew

If you installed a JDK through Homebrew (e.g., brew install openjdk@21), the files live in Homebrew's Cellar, not in /Library/Java/. Uninstall cleanly with:

brew uninstall openjdk@21
brew cleanup

List all Java-related Homebrew formulae first:

brew list | grep -i java
brew list | grep -i jdk

SDKMAN

SDKMAN keeps all its Java candidates inside ~/.sdkman/candidates/java/. To remove a specific version:

sdk uninstall java 21.0.3-tem

To remove SDKMAN entirely along with all its managed JDKs:

rm -rf ~/.sdkman

Then remove the lines SDKMAN added to your shell profile (~/.zshrc or ~/.bash_profile) that source ~/.sdkman/bin/sdkman-init.sh.

Cleaning Maven and Gradle Caches

The Maven local repository at ~/.m2/repository/ and Gradle's cache at ~/.gradle/caches/ can be the largest Java-related directories on a developer machine. These are entirely safe to delete — Maven and Gradle will re-download any dependencies your projects need the next time you build. They are just local mirrors, not project source files.

rm -rf ~/.m2/repository
rm -rf ~/.gradle/caches

If you want to keep the repository structure but free space from old artifact versions, you can selectively remove folders inside ~/.m2/repository/ by group ID (e.g., ~/.m2/repository/com/example/).

For context on how dependency caches fit into your overall storage picture, see what's taking up space on your Mac — the same hidden-folder patterns appear across Python, Node, and Ruby ecosystems too.

How to Remove Old JRE Installations

The standalone JRE (Java Runtime Environment) — once common for running desktop Java applications — was deprecated and is rarely installed on modern Macs. If you have a legacy JRE from Java 6 or earlier, it may live in:

• /System/Library/Java/JavaVirtualMachines/ — Apple's bundled Java 6 (read-only on modern macOS; only present on very old upgrades)
• /Library/Java/JavaVirtualMachines/ — third-party JRE packages

To check for Apple's legacy Java 6 specifically:

ls /System/Library/Java/JavaVirtualMachines/

On macOS Sequoia and Tahoe, this directory is typically absent or contains nothing user-removable. If it exists, these files are part of the sealed system volume and cannot be deleted without disabling System Integrity Protection — which is not recommended for the space savings involved.

Checking for jenv and Shell PATH Remnants

If you used jenv to manage JDK switching, remove it along with its shims:

rm -rf ~/.jenv

Then open your ~/.zshrc (or ~/.zprofile) and remove any lines that reference jenv, JAVA_HOME, or paths into /Library/Java/JavaVirtualMachines/. After editing, run source ~/.zshrc to reload your shell.

You can also check what JAVA_HOME is currently set to:

echo $JAVA_HOME

If it still points to a JDK you've deleted, the removal will show an error next time something tries to use it. Clearing it from your shell profile resolves this.

How Much Space Will You Actually Recover?

The JDK bundles themselves typically run 300–700 MB each, so removing three or four accumulated versions can free 1–2 GB from /Library/Java/JavaVirtualMachines/ alone. The real surprise is usually ~/.gradle/caches/ and ~/.m2/repository/: on a machine used for active Java development, these can grow to 5–15 GB without any obvious prompt. If you're doing a thorough audit of developer tool residue — Java, Node modules, Python virtual environments, Xcode derived data — a tool like Crumb can scan all of these locations at once and show you the sizes before you commit to deleting anything.

For a broader look at developer tool disk usage, the guide on cleaning up node_modules on Mac covers the same pattern of hidden caches that accumulate silently in project directories.