jenv for JVM Version Management

JVM version per project.

Installing

jenv installation is platform-specific but quick. Mac via Homebrew; Linux from upstream GitHub releases. Once installed, the shell hook is the piece that makes auto-switching work.

• Mac: brew install jenv. Standard path; Homebrew handles upgrades and PATH plumbing.
• Linux: GitHub releases. Manual install from upstream; standard package managers usually do not have it.
• jenv add and jenv versions. Register each installed JVM (8, 11, 17, 21) so jenv knows what is available; jenv versions lists registered versions.
• Shell hook. Add eval "$(jenv init -)" to .zshrc or .bashrc; this is what makes per-directory switching automatic.

Per-project version

Per-project pinning is the daily discipline. .java-version in the repo means the whole team gets the right JVM the moment they cd into the project.

• jenv local 17.0.5. Pins the per-directory version into .java-version; jenv reads it on every cd.
• Commit .java-version to git. Version-control the JVM requirement; new contributors get the right version without asking.
• JAVA_VERSION override. Environment variable override for one-off testing without modifying the file.
• Documented JVM requirement per project. README mention of the required JVM; the .java-version file is the source, the README is the signpost.

Global default

The global default is the fallback for directories without a local pin. Workstation-wide; per-project overrides take precedence whenever they are present.

• jenv global 21.0.1. Workstation-wide default; applies in any directory that does not have its own .java-version.
• Local overrides take precedence. Per-shell behaviour: if a parent directory has a .java-version, that wins over global.
• Periodic review of registered JVMs. Old major versions accumulate; quarterly review and cleanup reclaims disk.
• Documented setup per engineer. Dotfiles entry covering jenv install, registered versions, and global default; the discipline survives machine moves.

Versus alternatives

jenv has alternatives that solve overlapping problems. Pick by whether you need polyglot support and how much you want the tool to install JVMs for you.

• asdf: multi-language. Java, Node, Python, Ruby, Go all under one tool; heavier than jenv but covers the whole stack.
• SDKMAN: similar to jenv with installer. JVM-focused, includes JDK auto-discovery and install; choose if you want sdk install java to do it all.
• Pick by polyglot needs. JVM-only teams: jenv. Polyglot teams: asdf. Java-only with installer convenience: SDKMAN.
• Documented team choice. Pick one tool and put it in the README; "different on every laptop" is the failure mode that breaks new-hire onboarding.