To brew install Java 17 on a Mac, run brew install --cask temurin@17 for the Eclipse Temurin build, or brew install openjdk@17 for the Homebrew OpenJDK formula, then point JAVA_HOME at the new JDK. Both give you a fully supported OpenJDK 17 (a long-term support release), and the choice between them mostly comes down to whether you want Homebrew to manage the version or you want the vendor build that most production environments run. This guide covers both paths, the JAVA_HOME wiring people forget, and why keeping the JDK current is a security decision, not just a housekeeping one.
First, install Homebrew if you have not
If brew is not on your machine yet, install it from the official script, then confirm it works:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew --version
On Apple Silicon, Homebrew lives under /opt/homebrew; on Intel Macs it is /usr/local. That prefix matters later for the symlink step, so note which one you have with brew --prefix.
Option A: the Temurin cask (recommended for most)
Eclipse Temurin, from the Adoptium project, is the free OpenJDK distribution most teams standardize on, and it is what a lot of CI images and servers already run. Installing the Java 17 cask gives you a proper macOS JDK package:
brew install --cask temurin@17
The cask installs into the system JVM location, so /usr/libexec/java_home picks it up automatically. Verify:
/usr/libexec/java_home -V # lists all JDKs macOS knows about
java -version # should report 17.x
This is the cleanest way to install java 17 on mac if you want your local JDK to match a Temurin-based production runtime.
Option B: the openjdk@17 formula
If you prefer Homebrew to own the version and handle upgrades through brew upgrade, use the formula instead:
brew install openjdk@17
The formula is "keg-only," meaning Homebrew does not link it into your path by default and macOS will not find it through java_home without help. You have to create the symlink yourself. On Apple Silicon:
sudo ln -sfn /opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk \
/Library/Java/JavaVirtualMachines/openjdk-17.jdk
On an Intel Mac, swap /opt/homebrew for /usr/local. This symlink is the step people miss, and it is why brew install java (which pulls the unversioned openjdk formula) so often leaves someone with a JDK that java_home cannot see. Prefer the explicit openjdk@17 formula over the bare install java using brew command so you know exactly which major version you got.
Set JAVA_HOME so everything finds the JDK
Regardless of which route you took, set JAVA_HOME in your shell profile so build tools, IDEs, and scripts resolve the right JDK. Add this to ~/.zshrc (the default shell on modern macOS):
export JAVA_HOME=$(/usr/libexec/java_home -v 17)
export PATH="$JAVA_HOME/bin:$PATH"
Reload with source ~/.zshrc, then confirm:
echo $JAVA_HOME
javac -version
Using java_home -v 17 rather than a hardcoded path means the export keeps working after a patch upgrade moves the exact version directory.
Running more than one JDK
Plenty of Macs need Java 17 alongside Java 21 or an older 11. The java_home tool already lets you switch per shell:
export JAVA_HOME=$(/usr/libexec/java_home -v 17) # this terminal uses 17
For frequent switching, a version manager like jenv or SDKMAN handles per-project defaults more comfortably than editing exports by hand. If you install a Java runtime through the brew install java runtime route expecting only a JRE, note that modern OpenJDK distributions ship a full JDK rather than a separate cut-down JRE, so you get the compiler and tools regardless.
Why the version you install is a security matter
A JDK is not a set-and-forget install. OpenJDK ships quarterly Critical Patch Updates that fix real vulnerabilities in the runtime, the crypto libraries, and the XML and deserialization machinery your applications lean on. Installing "Java 17" and never touching it again means running whatever flaws existed on that day.
The advantage of installing through Homebrew is that upgrades are one command. Keep it current:
brew upgrade --cask temurin@17 # for the cask
brew upgrade openjdk@17 # for the formula
The same logic extends to your projects. The JDK is one dependency; your Maven and Gradle trees pull in dozens more, and a patched runtime does nothing for a vulnerable library sitting in your build. Scanning those dependencies (an SCA tool such as Safeguard can flag known-vulnerable JARs transitively) is the other half of keeping a Java stack safe. Our DevSecOps academy covers wiring dependency scanning into a Maven or Gradle build.
FAQ
Should I use the Temurin cask or the openjdk formula?
Use the Temurin cask (brew install --cask temurin@17) if you want a vendor build that matches most production environments and installs where macOS finds it automatically. Use brew install openjdk@17 if you want Homebrew to manage the version through brew upgrade, and accept the extra symlink step.
Why can't Java see my JDK after brew install openjdk@17?
The openjdk formula is keg-only and is not symlinked into the system JDK location. Create the symlink into /Library/Java/JavaVirtualMachines, then macOS java_home will list it. The Temurin cask avoids this because it installs as a proper macOS package.
How do I set JAVA_HOME for Java 17 specifically?
Add export JAVA_HOME=$(/usr/libexec/java_home -v 17) to your ~/.zshrc. The -v 17 selector pins the major version while surviving patch upgrades that change the exact directory name.
How do I keep Java 17 patched?
Run brew upgrade --cask temurin@17 (cask) or brew upgrade openjdk@17 (formula) regularly. OpenJDK issues quarterly security updates, so an unpatched JDK accumulates known runtime vulnerabilities over time.