Introduction

The practical problem on macOS is not just installing Java. It is switching between multiple JDKs without breaking your shell, IDE, or build tools. The two common approaches today are:

• install JDKs with Homebrew and switch them with jenv
• install and switch them with SDKMAN!

Both work. The better choice depends on whether you prefer a general macOS package manager or a language-specific version manager.

Homebrew Plus jenv Is a Strong macOS-Native Workflow

If you already use Homebrew for developer tooling, installing JDKs with Brew and switching them with jenv is a clean setup.

Install a couple of JDKs:

brew install openjdk@17
brew install openjdk@21
brew install jenv

Then initialize jenv in your shell:

echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.zshrc
echo 'eval "$(jenv init -)"' >> ~/.zshrc
source ~/.zshrc

Next, discover your installed JDKs:

/usr/libexec/java_home -V

Add each one to jenv:

jenv add /opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk/Contents/Home
jenv add /opt/homebrew/opt/openjdk@21/libexec/openjdk.jdk/Contents/Home

Now you can switch versions globally, per shell, or per project.

jenv global 21
jenv shell 17
jenv local 17

That project-local switch is especially useful when one repo still needs Java 17 while another already uses Java 21.

SDKMAN! Is Simpler If You Want Java-Centric Version Management

If your main goal is "install JDKs and switch them easily", SDKMAN! is often the most direct tool.

1curl -s "https://get.sdkman.io" | bash
2source "$HOME/.sdkman/bin/sdkman-init.sh"
3
4sdk install java 17-tem
5sdk install java 21-tem
6sdk use java 17-tem
7sdk default java 21-tem

This is appealing because installation and switching are both handled in one tool instead of split across Homebrew and jenv.

Check What Java the System Is Actually Using

After switching, verify both the shell view and the Java runtime itself:

java -version
which java
echo "$JAVA_HOME"

On macOS, it is easy to think a version switch worked when only one of these changed. Always verify the full toolchain, especially before debugging Gradle or Maven issues.

Project-Level Switching Is the Real Win

The best reason to use jenv or SDKMAN! is not the one-time install. It is the ability to pin the right Java version per project.

With jenv, jenv local 17 writes a .java-version file into the project. That lets the shell switch automatically when you enter the directory. It is a small feature, but it prevents a lot of accidental "works on my machine" problems.

Similarly, sdk env workflows can make project-specific Java selection repeatable.

Watch Out for IDE and Build Tool Mismatch

Shell switching alone is not enough if IntelliJ, Gradle, or Maven is configured to use a different JDK. The usual failure pattern is:

• terminal says Java 17
• IDE uses Java 21
• build behaves differently depending on where it was run

So after switching the shell JDK, also check:

• IDE project SDK
• Gradle JVM setting
• Maven toolchain or JAVA_HOME usage

Version switching is only successful when the entire development path agrees.

Common Pitfalls

• Following old tutorials that reference outdated Homebrew cask names such as adoptopenjdk.
• Installing multiple JDKs but never wiring them into a switching tool.
• Forgetting to reload the shell after adding jenv or SDKMAN! initialization.
• Verifying only java -version and not checking JAVA_HOME or IDE settings.
• Assuming the shell switch automatically changes every tool that launches Java.

Summary

• On macOS, a good Java setup is really about installation plus reliable version switching.
• Homebrew with jenv is a strong choice if you already use Brew heavily.
• 'SDKMAN! is a strong choice if you want one Java-focused install-and-switch tool.'
• Always verify java -version, which java, and JAVA_HOME after switching.
• Check your IDE and build tools too, or the version manager will only solve half the problem.