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 java_home does not detect a JDK, common causes include:

• the JDK is not fully or correctly installed
• the installer version is too old or has a registration issue
• shell environment settings are pointing elsewhere
• the IDE is using its own configured JDK rather than the terminal default

Understanding installation paths, JAVA_HOME, and tool configuration is important because Java builds, IDEs, Gradle, Maven, and JavaFX all depend on the correct JDK being selected.

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 java and javac commands first.

If java_home does not return Java 8, reinstalling a proper JDK package is usually better than creating manual symlinks.

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 javac, the shell finds the Java 8 executables first.

4. java -version

   • Confirms the runtime version currently used in the terminal.

5. javac -version

   • Confirms the compiler version.

If both report 1.8, your terminal is correctly using Java 8.

If IntelliJ still uses another version, that means the IDE has its own project SDK settings that must be changed separately.

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

In IDEs, developers also configure:

• Project SDK: the JDK used to compile the project
• Module SDK: sometimes different per module
• Language level: should match or be compatible with the selected JDK

This separation is important: your terminal Java and IntelliJ Java can be different unless you configure both.

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.
• Check IntelliJ Project SDK separately.

4. Setting JAVA_HOME incorrectly

Broken example:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk

This is often incomplete because Java tools usually expect the Contents/Home directory.

Correct form:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home

Or better:

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

5. Forgetting to update PATH

If JAVA_HOME points to Java 8 but PATH still finds another java first, your terminal may keep using the wrong version.

Correct pattern:

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

6. Trusting outdated installation instructions

Java setup on macOS has changed over time.

How to avoid it:

• Prefer current vendor documentation.
• Verify with commands instead of assuming old folder layouts still apply.

Another useful comparison:

# 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?

No. That is usually unnecessary and can create a fragile setup. Use the standard JDK path and java_home or configure the IDE directly.

Can I have multiple Java versions installed on macOS?

Yes. This is common. You can switch between them using JAVA_HOME, java_home, shell configuration, or IDE-specific project settings.

• 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.