Introduction

To see all Java versions installed on a Mac, run /usr/libexec/java_home -V in Terminal. This built-in macOS utility lists every JDK it can find under /Library/Java/JavaVirtualMachines/, showing the version number, architecture, vendor, and installation path for each one.

/usr/libexec/java_home -V

Sample output:

1Matching Java Virtual Machines (3):
2    21.0.2 (arm64) "Eclipse Adoptium" - "OpenJDK 21.0.2" /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home
3    17.0.9 (arm64) "Eclipse Adoptium" - "OpenJDK 17.0.9" /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
4    11.0.21 (arm64) "Eclipse Adoptium" - "OpenJDK 11.0.21" /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home

Why Multiple Java Versions Exist on One Machine

Different projects often pin different Java versions. A legacy service might require Java 11 while a newer microservice targets Java 21. Build tools like Maven and Gradle respect JAVA_HOME, so switching versions per project is a normal part of Java development on macOS.

Homebrew, SDKMAN!, and manual .pkg installers all place JDKs in the same /Library/Java/JavaVirtualMachines/ directory, which is why multiple versions accumulate over time.

Checking the Active Java Version

The java_home -V command shows what is installed, but to see which version the current shell session is actually using, run:

java -version

This reports the version that the java binary on your PATH resolves to. If JAVA_HOME is set, most build tools use that value instead of whatever java -version reports.

To see exactly which binary your shell resolves:

which java

On modern macOS, this often points to /usr/bin/java, which is a shim that delegates to the JDK selected by java_home.

Switching Between Installed Versions

Setting JAVA_HOME Manually

The java_home utility can return the path for a specific version, which you can assign to JAVA_HOME:

export JAVA_HOME=$(/usr/libexec/java_home -v 17)

Add this line to your ~/.zshrc (or ~/.bash_profile for older macOS) to make it persistent. To switch versions, change the version number and reload your shell:

export JAVA_HOME=$(/usr/libexec/java_home -v 21)

Switching With a Shell Function

A shell function makes switching faster during active development:

1# Add to ~/.zshrc
2jdk() {
3    export JAVA_HOME=$(/usr/libexec/java_home -v "$1")
4    echo "JAVA_HOME set to $JAVA_HOME"
5    java -version
6}

Usage:

jdk 17
jdk 21

Using SDKMAN!

SDKMAN! is a version manager that handles installation and switching in one tool:

1# Install SDKMAN!
2curl -s "https://get.sdkman.io" | bash
3source "$HOME/.sdkman/bin/sdkman-init.sh"
4
5# List available versions
6sdk list java
7
8# Install a specific version
9sdk install java 21.0.2-tem
10
11# Switch for the current session
12sdk use java 17.0.9-tem
13
14# Set as default
15sdk default java 21.0.2-tem

SDKMAN! installs JDKs to ~/.sdkman/candidates/java/ rather than the system directory, so java_home -V will not list them. Use sdk list java instead when managing versions through SDKMAN!.

Comparison of Methods

Finding JDK Installation Paths

All standard macOS JDK installers place files under:

/Library/Java/JavaVirtualMachines/

You can list the directories directly:

ls /Library/Java/JavaVirtualMachines/

Each JDK lives in its own directory, typically named with the vendor and version:

temurin-17.jdk
temurin-21.jdk
zulu-11.jdk

The actual JAVA_HOME path points one level deeper:

/Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home

Removing Old Java Versions

Uninstalling a JDK is a matter of removing its directory:

sudo rm -rf /Library/Java/JavaVirtualMachines/temurin-11.jdk

If the JDK was installed via Homebrew:

brew uninstall --cask temurin11

If installed via SDKMAN!:

sdk uninstall java 11.0.21-tem

After removal, run /usr/libexec/java_home -V again to confirm the version is gone.

Checking Java Versions in Build Tools

Build tools have their own ways to report the Java version they are using:

1# Maven
2mvn -version
3
4# Gradle
5gradle --version
6
7# Output includes the JVM version and JAVA_HOME path

If the version reported by your build tool does not match java -version, check whether the tool has its own JAVA_HOME override in its configuration or wrapper script.

Apple Silicon vs. Intel Considerations

On Apple Silicon Macs, the architecture column in java_home -V output shows arm64. If you also have Rosetta-translated Intel JDKs installed, they appear as x86_64. Both architectures can coexist, but mixing them in the same build can cause issues with native libraries.

To filter by architecture:

/usr/libexec/java_home -V --arch arm64
/usr/libexec/java_home -V --arch x86_64

Common Pitfalls

Running java -version and assuming it reflects what your IDE or build tool uses is a frequent mistake. IDEs like IntelliJ IDEA maintain their own JDK configuration independent of JAVA_HOME. Always check the IDE's project settings separately.

Forgetting to reload the shell after editing ~/.zshrc means the JAVA_HOME change is not picked up. Run source ~/.zshrc or open a new terminal window after making changes.

Installing JDKs through multiple package managers (Homebrew, SDKMAN!, manual .pkg) leads to confusion about which versions exist where. Pick one manager and stick with it for consistency.

The java_home utility only scans /Library/Java/JavaVirtualMachines/. JDKs installed elsewhere (such as SDKMAN!'s ~/.sdkman/ directory) are invisible to it. If java_home -V shows fewer versions than you expect, check whether some were installed by a different tool.

Summary

• Run /usr/libexec/java_home -V to list all system-installed JDKs on macOS.
• Use java -version to check which version the current shell session is using.
• Set JAVA_HOME with export JAVA_HOME=$(/usr/libexec/java_home -v VERSION) to switch versions.
• Use SDKMAN! for a more integrated install-and-switch workflow.
• Remove old JDKs by deleting their directory under /Library/Java/JavaVirtualMachines/.
• Be aware that java_home does not see JDKs managed by SDKMAN! or installed outside the system directory.