How to Install and Configure Java 8 on Mac

By the end of this page, you will understand how Java is installed on macOS, why different Java versions appear in different system folders, how java_home discovers JDKs, and how to verify and configure Java 8 for terminal use and IDEs such as IntelliJ IDEA.

macOS has historically treated Apple's system-provided Java and user-installed Java differently.

Older Apple-provided Java versions were often stored in system-managed locations such as:

/System/Library/Java/JavaFrameworks/

Newer Oracle JDK versions, including Java 8, are typically installed in:

/Library/Java/JavaVirtualMachines/

This difference matters because:

• /System/Library is reserved for software managed by Apple.
• /Library is for software installed for the whole machine by users or third-party installers.
• Oracle's Java installer correctly uses /Library, not /System/Library.

So the location itself is usually not the problem.

The real concept behind this question is how macOS discovers installed JDKs and how tools choose which Java version to use.

On macOS, the command:

/ usr/libexec/java_home

normally checks installed JDK bundles and returns the best matching Java home path. Developers often use it to set JAVA_HOME, for example:

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

If does not detect a JDK, common causes include:

Think of macOS Java setup like a library building:

• /System/Library is the staff-only section managed by Apple.
• /Library is the public installed-software section where third-party packages go.
• java_home is the catalog desk that tells programs where a matching Java version lives.
• JAVA_HOME is the note you hand to your tools saying, "Use this Java installation."

So even if Java 8 is physically in the building, your tools still need the catalog desk or your environment variables to point to the right shelf.

The most common commands for checking and configuring Java on macOS are:

/usr/libexec/java_home -V
java -version
javac -version

To ask for a specific version:

/usr/libexec/java_home -v 1.8

To temporarily set Java 8 in your current shell:

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

Example:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    1.8.0_202, x86_64: "Java SE 8"    /Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home
    1.6.0_65-b14-468, x86_64: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

$ export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)
$ java -version
java version "1.8.0_202"

What this does:

• java_home -V lists installed JDKs that macOS recognizes.
• java_home -v 1.8 returns the path for Java 8.
• JAVA_HOME tells Java-based tools which JDK to use.
• updating PATH makes the shell use that JDK's and commands first.

Consider this shell session:

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

Step by step:

1. /usr/libexec/java_home -V

   • macOS scans known Java bundle locations.
   • It lists every JDK it can identify.
   • If Java 8 is missing here, the OS is not recognizing that installation properly.

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

   • The shell runs java_home -v 1.8.
   • That command returns a path such as:

     /Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home
     

   • JAVA_HOME is set to that path.

3. export PATH="$JAVA_HOME/bin:$PATH"

   • The shell puts Java 8's bin directory at the front of PATH.
   • Now when you type java or , the shell finds the Java 8 executables first.

This concept shows up in many practical situations:

• Running JavaFX apps: JavaFX versions often require a specific JDK.
• Building Maven or Gradle projects: the build may fail if the wrong Java version is active.
• Working on legacy systems: one project may need Java 8 while another needs Java 17.
• Using IntelliJ or Eclipse: the IDE may have a different JDK than your terminal.
• CI and automation scripts: deployment scripts often set JAVA_HOME explicitly.
• Command-line tools: Android, build tools, and application servers often depend on Java environment variables.

Example scenario:

A developer has:

• an old enterprise app that requires Java 8
• a newer service that uses Java 17

They use JAVA_HOME and version-specific paths so each project builds with the correct JDK instead of whichever one happens to come first in PATH.

In real projects, developers usually do not rely only on whatever java happens to resolve to.

Common patterns include:

• Explicit JAVA_HOME setup in shell startup files such as ~/.zshrc or ~/.bash_profile
• Project-specific SDK selection in IntelliJ IDEA
• Build-tool configuration in Gradle or Maven
• Validation scripts that check the Java version before building
• Early failure when the wrong JDK is active

Example of a shell guard in a build script:

if ! java -version 2>&1 | grep '1.8' > /dev/null; then
  echo "Java 8 is required for this project."
  exit 1
fi

Example of a safer pattern using JAVA_HOME:

if [ -z "$JAVA_HOME" ]; then
  echo "JAVA_HOME is not set"
  exit 1
fi

"$JAVA_HOME/bin/java" -version

Here are common mistakes beginners make when setting up Java on macOS.

1. Installing the JRE instead of the JDK

The JRE can run Java programs, but it does not include javac for compiling code.

Broken expectation:

java -version
javac -version

If java works but javac does not, you may have installed only a runtime.

How to avoid it:

• Install a full JDK, not just a JRE.
• Check both java -version and javac -version.

2. Manually editing system folders or symlinking into /System/Library

/System/Library is not where third-party Java should be installed.

How to avoid it:

• Do not move the JDK into Apple-managed paths.
• Use the installed path under /Library/Java/JavaVirtualMachines/.

3. Assuming the terminal and IntelliJ use the same Java

They often do not.

How to avoid it:

• Check Java in the terminal with java -version.

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

# Get the path for Java 8
/usr/libexec/java_home -v 1.8

# Check runtime version
java -version

# Check compiler version
javac -version

# Set Java 8 for current shell session
export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)
export PATH="$JAVA_HOME/bin:$PATH"

Key rules:

• Java 8 on macOS is normally installed under /Library/Java/JavaVirtualMachines/
• Do not move it into /System/Library
• JAVA_HOME should usually point to .../Contents/Home
• java -version checks the runtime currently used
• javac -version checks the compiler
• IntelliJ SDK settings are separate from terminal settings

If Java 8 is not detected:

• confirm you installed a JDK, not just a runtime
• reinstall the JDK from a reliable source
• check /Library/Java/JavaVirtualMachines/
• run /usr/libexec/java_home -V
• configure IntelliJ manually if needed

Why is Java 8 installed in /Library instead of /System/Library on Mac?

/System/Library is reserved for Apple-managed software. Third-party JDKs such as Oracle Java are normally installed in /Library.

Why does java_home not find my Java 8 installation?

Usually because the JDK was not registered correctly, the installation is incomplete, or the installed package is outdated or incompatible with the OS.

What is the correct JAVA_HOME for a macOS JDK?

It is usually the Contents/Home directory inside the .jdk bundle, for example:

/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home

Is java -version enough to verify Java setup?

Not always. Also check javac -version if you plan to compile code, because a runtime-only install may not include the compiler.

Why does IntelliJ still show the wrong Java version?

IntelliJ can use a separately configured Project SDK. You may need to update the SDK in the project settings even if the terminal uses Java 8.

Should I create symlinks to make Java appear under old system folders?

• JAVA_HOME — Environment variable used by Java tools to locate the active JDK.
• PATH environment variable — Controls which java and javac executables the shell finds first.
• JDK vs JRE — Important for understanding why some installations can run Java but not compile code.
• IntelliJ Project SDK — Relevant because IDE Java configuration can differ from terminal Java.
• Command-line environment variables — Useful for setting language runtimes and tool behavior.
• Java version management — Important when working with multiple Java versions across projects.
• macOS filesystem layout — Helps explain the difference between /System/Library and /Library.