One Dev, Many JDKs: The Ultimate 2025 Setup Guide for Java on Any OS

Whether you're maintaining a legacy Java 8 app or building with Java 24, switching between JDKs shouldn't feel like breaking production.

This 2025 guide helps you install and manage multiple Java versions — cleanly and confidently — across macOS, Windows, and Linux.

Why Multiple Java Versions?

Java keeps evolving. But not every project moves at the same speed.

• Legacy: Java 8
• LTS: Java 17
• Latest: Java 24 (as of writing this post)

If you work on multiple projects, you need version switching — not uninstalling.

In my career, I have come across many companies which wait until they absolutely need to upgrade to the next LTS version of Java. And when this occurs you find yourself having to switch between versions, until every application has been upgraded.

I found SDKMAN to be good solution for this. SDKMAN installs and switches JDK versions globally or per shell session.

For macOS/Linux: Use SDKMAN

Install SDKMAN

curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"

Install switch JDKS

sdk install java 17.0.9-tem
sdk use java 17.0.9-tem
sdk default java 8.0.382-tem

Want Project-Level Control?

Use jEnv

jEnv manages which JDK is used per project, using .java-version files or shell commands.

brew install jenv

Add JDKs

jenv add /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
jenv global 17
jenv local 8

For Windows: Manual Setup + Scripts

SDKMAN doesn’t support Windows natively, but you can still manage JDKs:

Install Multiple JDKs

Download from:

• Adoptium
• Oracle
• Zulu

Switch with JAVA_HOME

Update JAVA_HOME and %PATH% manually or via batch scripts. Optionally try jabba for a CLI-based manager (works on WSL too).

Common Pitfalls to Avoid

• Forgetting to update JAVA_HOME
• Mixing JDK vendors
• Not using .java-version files
• Breaking PATH accidentally
• Relying only on system-wide configs

Summary Table