Introduction

On macOS, JAVA_HOME is not a fixed string you should hardcode blindly. From Lion through Mojave, the reliable way to discover the active JDK home is /usr/libexec/java_home, which resolves the correct Contents/Home path for the installed Java version you want.

Core Sections

The command Apple expects you to use

macOS provides /usr/libexec/java_home specifically for this purpose. If Java is installed correctly, it prints the selected JDK home directory.

/usr/libexec/java_home

To list all detected JDKs:

/usr/libexec/java_home -V

This is better than guessing paths because different JDK vendors and versions can coexist on the same machine.

What the actual path usually looks like

For Oracle, OpenJDK, Temurin, and similar modern installs, the physical JDK directories are commonly under:

/Library/Java/JavaVirtualMachines/

A specific JDK home typically looks like this:

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

That final Contents/Home directory is what tools usually expect in JAVA_HOME, not the .jdk bundle root.

Older Apple-provided Java 6 installs on older macOS versions may appear under Apple-managed locations, but even there, java_home is the safer interface because it hides those layout differences.

Set JAVA_HOME in your shell

For a temporary shell session:

export JAVA_HOME=$(/usr/libexec/java_home)
echo "$JAVA_HOME"

To pin a specific version, pass -v.

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

Then persist it in your shell startup file. For example, in ~/.zshrc:

export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)
export PATH="$JAVA_HOME/bin:$PATH"

Open a new shell or run source ~/.zshrc afterward.

Understand the version differences from Lion to Mojave

From Lion through older macOS releases, Apple’s own Java 6 was part of the platform story for many systems. By the time you reach newer releases such as High Sierra and Mojave, Java is no longer something to assume is present by default for development use. That is why hardcoded advice like “JAVA_HOME is always here” ages badly.

The cross-version rule that remains dependable is:

• install the JDK you actually want
• use /usr/libexec/java_home to resolve it
• export that result into JAVA_HOME

That approach is stable even if the on-disk directory name changes.

Verify what your tools are seeing

After setting the variable, confirm both the shell and Java agree.

echo "$JAVA_HOME"
java -version
javac -version

If java -version shows one JDK but JAVA_HOME points somewhere else, your shell configuration and your effective runtime path are out of sync.

This often happens when developers install multiple JDKs and update only one piece of the environment.

Avoid hardcoding when possible

Build tools such as Maven, Gradle, and IDEs often honor JAVA_HOME, so setting it correctly once is useful. But scripting with /usr/libexec/java_home directly is often even safer than embedding a full vendor-specific path in shared scripts.

That keeps team machines and CI environments more portable.

Common Pitfalls

• Hardcoding a single JDK bundle path and assuming it will survive upgrades, vendor changes, or multiple installed JDKs.
• Setting JAVA_HOME to the .jdk bundle root instead of the actual Contents/Home directory.
• Updating JAVA_HOME in the current shell only and forgetting to persist it in the shell startup file.
• Assuming older macOS versions and newer ones manage Java in exactly the same way.
• Checking only java -version and not verifying that JAVA_HOME and the PATH are aligned with the intended JDK.

Summary

• On macOS Lion through Mojave, the best way to find Java home is /usr/libexec/java_home.
• Modern JDKs usually live under /Library/Java/JavaVirtualMachines/.../Contents/Home.
• Set JAVA_HOME from java_home rather than hardcoding a guessed path.
• Use -V to list installed JDKs and -v to choose a specific version.
• Verify the shell, compiler, and runtime all point to the same JDK after configuration.