Backend

SDKMAN, jEnv, and JetTUI: Three Philosophies for JDK Version Management

By 极客悟道 · Jul 31, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

JVM developers routinely juggle multiple JDK and Maven versions across projects, and the wrong tool for your platform and workflow turns a five-second switch into a recurring terminal fight. This comparison maps each tool's trade-offs to concrete use cases so the decision comes down to OS, project structure, and whether you want an installer or just a switcher.

Summary

Three JDK version managers embody three distinct philosophies. SDKMAN acts as a full-service installer and switcher for the entire JVM ecosystem but remains Unix-only. jEnv focuses exclusively on fine-grained JDK switching—global, per-directory, per-shell—and leaves installation to the user. JetTUI wraps version switching into a Windows-native terminal dashboard that also compiles, packages, and manages Spring Boot services.

The comparison breaks down across six dimensions: platform support, interaction style, switching granularity, download capabilities, persistence, and additional tooling. jEnv's directory-level auto-switching via `.java-version` files is unmatched for multi-project workflows. JetTUI's native Windows support and built-in build controls give it a distinct edge for developers on that platform. SDKMAN's ability to fetch and install JDKs and other SDKs with a single command makes it the fastest path to trying new versions.

No tool wins across the board. The choice hinges on operating system, whether you want automatic directory-based switching, and whether you value an integrated build-and-run environment over a pure version manager.

Takeaways

— SDKMAN downloads and installs JDKs, Maven, Gradle, and other JVM-ecosystem tools automatically; it does not support directory-level auto-switching and runs natively only on Unix-like systems.

— jEnv provides three-tier switching—global, per-directory via `.java-version`, and per-shell—but requires users to install JDKs themselves and manages nothing beyond the JDK.

— JetTUI is a Windows-native TUI dashboard where version switching (F4) sits alongside compile (F2), package (F3), and Spring Boot service management (F1) with separate log views.

— Directory-level auto-switching is jEnv's standout feature: `jenv local 17` writes a `.java-version` file that triggers automatic JDK selection when entering that directory.

— JetTUI writes `JAVA_HOME`, `MAVEN_HOME`, and `PATH` directly to Windows user environment variables, so changes persist across new terminals without a separate daemon or shim.

— All three tools can be combined—SDKMAN for installation, jEnv for directory switching, JetTUI for build and run controls—but most developers only need one.

Conclusions

The JDK version-management landscape splits along a fault line that matters more than features: whether the tool also installs the JDK for you. SDKMAN's download capability eliminates a whole class of friction that jEnv and JetTUI leave to the user.

jEnv's directory-level auto-switching is the only mechanism that removes human memory from the equation entirely—no command to run, no tab to click—which makes it the strongest choice for repos with divergent JDK requirements checked out side by side.

JetTUI's bundling of version switching with build and service controls reflects a practical truth: switching a JDK is rarely the goal; it's a prerequisite to compiling or running something. Collapsing those steps into one interface reduces context-switching overhead.

Windows support remains the decisive filter. Two of the three tools are Unix-first, and while WSL bridges the gap, the experience degradation is real enough that a native TUI tool with fewer features can still be the pragmatic pick.

Concepts & terms

Shim mechanism (jEnv)

A lightweight interception layer that jEnv inserts into the system PATH. When a command like `java` is invoked, the shim intercepts it, checks which JDK version should be used for the current context (global, directory, or shell), and forwards the call to the correct JDK binary.

TUI (Text-based User Interface)

A graphical interface rendered entirely in a terminal using text characters, supporting mouse clicks, buttons, and input fields. JetTUI uses a TUI to provide a dashboard-like experience without leaving the terminal.

From the discussion

The discussion pushes back on the premise that manual JDK switching is still a problem. One view holds that IDEs and AI tools already handle version selection through full paths, making dedicated managers unnecessary. A counterpoint argues that IDE-level switching doesn't cover command-line use, and that installing a heavyweight dev tool just to flip a JDK version is overkill. The exchange exposes a split between developers who live entirely inside an IDE and those who need shell-level version changes.

— Modern IDEs and AI tools already manage JDK versions internally, so manual switching is a solved problem for many workflows.

— IDE-based version selection does not affect the command line, leaving a gap that dedicated managers fill.

— Installing a full development tool solely for JDK switching is excessive when lighter alternatives exist.

— The article's directory-level switching comparison is useful for understanding the different approaches.

Featured comments

你也想起舞吗彡 1 likes

Who on earth is still switching versions manually? Isn't version switching built into every dev tool? AI can just access it via the full path too.

极客悟道

But if you just want to switch a version, why install an extra dev tool? And most dev tools only take effect inside the tool itself, not on the command line.

你也想起舞吗彡 → 极客悟道 · 1 likes

You mean you just install a JDK and don't do any development?

See top comments, translated →

Source: juejin.cn ↗ Google Translate ↗ Backup ↗