Find Java Installation Paths on macOS for JNI

On macOS, the reliable way to locate an installed JDK is /usr/libexec/java_home. A Java JRE installation may only provide a browser/runtime plugin and may not create a JDK directory or include the JNI header files required for native development. For JNI, install a full JDK and use its Contents/Home directory as JAVA_HOME.

Java installations on macOS can be confusing because Java may mean either a runtime environment or a development kit.

• A JRE (Java Runtime Environment) runs Java applications.
• A JDK (Java Development Kit) includes the JRE plus development tools such as javac, javadoc, and the JNI C/C++ headers.

JNI development requires a JDK, because native code must include files such as:

include/jni.h
include/darwin/jni_md.h

A typical Oracle JDK 7 installation was stored as a versioned bundle under:

/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk

The actual Java home directory inside that bundle is:

/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home

Do not rely on a hard-coded version path. macOS provides /usr/libexec/java_home, a utility that finds installed JDKs and returns the correct Contents/Home path.

Think of a JRE as a car you can drive, while a JDK is a mechanic's workshop containing the car plus the tools needed to build and repair it.

Running a Java program only needs the car (the JRE). Building Java code or compiling JNI native libraries needs the workshop (the JDK).

The /Library/Java/JavaVirtualMachines directory is like a parking garage for installed JDK bundles. If it is empty, you may have installed only a runtime component rather than the full development kit.

Use the macOS java_home tool to list JDKs that the system can detect:

/usr/libexec/java_home -V

The uppercase -V displays installed JVMs and their locations. For example, it may show:

Matching Java Virtual Machines (1):
    1.7.0_17 (x86_64) "Oracle Corporation" - "Java SE 7" \
    /Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home

Get the path for the default JDK:

/usr/libexec/java_home

Get a specific Java major version:

/usr/libexec/java_home -v 1.7

Store the result in the JAVA_HOME environment variable for the current Terminal session:

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

Confirm that this is a JDK by checking for the Java compiler and JNI header:

ls "$JAVA_HOME/bin/javac"
ls "$JAVA_HOME/include/jni.h"

If both files exist, you have found a usable JDK for JNI.

Consider this Terminal session:

export JAVA_HOME="$(/usr/libexec/java_home -v 1.7)"
echo "$JAVA_HOME"
ls "$JAVA_HOME/include/jni.h"

1. /usr/libexec/java_home -v 1.7 asks macOS to find an installed JDK compatible with Java 7.
2. $(...) runs that command and substitutes its output into the surrounding command.
3. export JAVA_HOME=... creates an environment variable named JAVA_HOME for commands launched from this shell.
4. echo "$JAVA_HOME" prints the selected JDK home, often a path ending in Contents/Home.
5. ls "$JAVA_HOME/include/jni.h" checks for the JNI header. If the file is listed, native code can include jni.h.

For example, a successful value could be:

/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home

If java_home reports that no matching JVM exists, install a full JDK rather than only a JRE or browser plugin.

• Compiling a JNI library: A C or C++ build needs jni.h and the macOS-specific jni_md.h header.
• Build tools: Maven, Gradle, and IDEs use JAVA_HOME to select the JDK used for compilation.
• CI scripts: Build scripts often set JAVA_HOME explicitly so every build uses the intended Java version.
• Supporting multiple projects: One project may require Java 8 while another requires Java 17; java_home -v selects the required JDK.
• Troubleshooting: Comparing java -version, javac -version, and JAVA_HOME helps identify a runtime/development-version mismatch.

Projects usually avoid embedding a fixed path such as jdk1.7.0_17.jdk in build scripts. Versioned directory names change whenever Java is updated.

A shell script can resolve the required JDK dynamically:

#!/usr/bin/env bash
set -euo pipefail

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

if [ ! -f "$JAVA_HOME/include/jni.h" ]; then
  echo "A JDK with JNI headers is required." >&2
  exit 1
fi

clang -I"$JAVA_HOME/include" \
      -I"$JAVA_HOME/include/darwin" \
      -dynamiclib native_example.c \
      -o libnative_example.dylib

This pattern has two useful parts:

• It uses java_home rather than a machine-specific installation path.
• It validates that the needed JNI header exists before attempting compilation.

For a persistent interactive-shell setting, developers may add an appropriate JAVA_HOME export to their shell configuration file. A project-specific script or version manager is often safer when different projects require different Java versions.

Installing a JRE when JNI requires a JDK

A runtime can run Java programs but may not include JNI headers or javac.

# This can fail when only a runtime is installed.
ls /Library/Java/JavaVirtualMachines/*/Contents/Home/include/jni.h

Avoid it: install a full JDK, then verify jni.h through JAVA_HOME.

Using the java executable path as JAVA_HOME

This is not a Java home directory:

export JAVA_HOME="$(which java)"  # Incorrect

which java usually returns an executable or a system launcher, not the JDK root.

Use this instead:

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

Hard-coding a specific update directory

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home

This works only while that exact version remains installed.

Avoid it: use /usr/libexec/java_home -v 1.7 when a Java 7 JDK is required.

Forgetting the platform-specific include directory

jni.h includes platform-dependent definitions. On macOS, compiling JNI code commonly needs both directories:

clang -I"$JAVA_HOME/include" -I"$JAVA_HOME/include/darwin" native.c

Assuming an empty JavaVirtualMachines directory means Java cannot run

A browser plugin or runtime component can exist outside that JDK directory. An empty directory is strong evidence that a full JDK is not installed or not being detected, not necessarily that every Java-related component is absent.

A JDK bundle path and its Java home are also different:

# List all JDKs macOS can find
/usr/libexec/java_home -V

# Print the default JDK home
/usr/libexec/java_home

# Print a Java 7 JDK home
/usr/libexec/java_home -v 1.7

# Set JAVA_HOME for the current shell
export JAVA_HOME="$(/usr/libexec/java_home -v 1.7)"

# Verify the compiler and JNI header
"$JAVA_HOME/bin/javac" -version
ls "$JAVA_HOME/include/jni.h"

# Typical JNI compilation flags on macOS
clang -I"$JAVA_HOME/include" -I"$JAVA_HOME/include/darwin" native.c

Key rules:

• JNI requires a JDK, not merely a JRE.
• Prefer /usr/libexec/java_home over hard-coded versioned paths.
• JAVA_HOME should point to a directory ending in Contents/Home.
• An empty /Library/Java/JavaVirtualMachines directory usually means a JDK is missing or not registered there.

Where is a JDK usually installed on macOS?

A typical JDK is installed beneath /Library/Java/JavaVirtualMachines/. Its Java home is inside the bundle at .../Contents/Home.

How do I find Java's installation directory on macOS?

Run:

/usr/libexec/java_home

Use -V to list all detected JDK installations.

Why is /Library/Java/JavaVirtualMachines empty?

You may have installed a JRE, browser plugin, or another runtime component rather than a complete JDK. Install a JDK if you need javac or JNI headers.

What should JAVA_HOME be for JNI?

It should be the JDK home directory returned by /usr/libexec/java_home, such as a path ending in Contents/Home.

How can I check whether I have the JNI headers?

Run:

ls "$(/usr/libexec/java_home)/include/jni.h"

If the file does not exist, the selected installation is not a usable JDK for JNI.

Is which java a good way to find JAVA_HOME?

No. It locates the java launcher executable, not the root directory of a JDK. Use /usr/libexec/java_home instead.

Do I need the darwin include directory on macOS?

Usually yes. JNI C/C++ compilation commonly needs both $JAVA_HOME/include and $JAVA_HOME/include/darwin.

• JDK vs JRE — explains why runtime-only installations cannot compile Java or JNI code.
• JAVA_HOME environment variable — lets build tools and scripts locate a selected JDK.
• JNI (Java Native Interface) — the API that connects Java code with C or C++ native libraries.
• Shell environment variables — explains export, command substitution, and per-shell configuration.
• C/C++ compiler include paths — required to provide the compiler with the locations of jni.h and jni_md.h.
• Java version management — useful when separate applications require different JDK versions.