SDKMAN! CLI: the Shell Tool for Switching SDK Versions on Unix

The problem: parallel SDK versions on one Unix machine

A developer machine that builds more than one Java service usually ends up with several JDKs, and the shell has to pick one per terminal. SDKMAN! CLI exists to make that choice a command instead of an edit to JAVA_HOME. The README describes it as "a tool for managing parallel Versions of multiple Software Development Kits on any Unix-based system", with a command-line interface for installing, switching, removing and listing what it calls Candidates. The audience is therefore narrow and specific: Unix users who need more than one version of a kit on the same account, and who are willing to manage that from a terminal. Windows is not in scope, which matches the platform question people keep asking about it.

What the repository actually contains

This is a Shell project, and the layout confirms it. The top level holds bin/, contrib/, src/, a Gradle build (build.gradle, settings.gradle, gradlew), a Dockerfile, and an .sdkmanrc file. The README points to src/test/resources/features for the BDD tests that describe CLI behaviour, written in Cucumber and run through Gradle. So the shell functions are the product, and the Java side is the test and packaging harness around them. That split matters when you evaluate contributions: the README states that all commands are being rewritten in Rust in a separate project, sdkman-cli-native, that supplements this one, and that only bug fixes to supporting code will be accepted here. The last push to this repository was on 2026-09-19, alongside release 5.23.1, so the code is still moving, but the direction of travel is stated plainly in the notice rather than left to inference.

Installing SDKMAN! CLI and running a first sdk env install

The README gives a single install line for a Unix terminal. It pipes a remote script into bash, so read it before you run it if your environment has rules about that.

Where the shell approach breaks down

Two limits are visible from the repository itself. First, the platform boundary is absolute: the README says Unix-based systems, and the install line assumes a POSIX shell, so Windows users are outside the supported path. Second, the maintenance notice is a real constraint on adoption, not a footnote. A team that needs a new subcommand, a new candidate type or a behaviour change will not get it merged here; the README says no further enhancements will be accepted on the commands in this project and that they will be phased out in due course. The compensating benefit is stability: bug fixes to supporting code are still accepted, and the wrapper role described in the notice means existing scripts that call sdk should keep working through the transition. The README does not document rollback of a failed install, so treat an interrupted install as an unknown state rather than something you can undo with a documented command.

SDKMAN! CLI next to asdf and jenv

The closest alternatives solve the same problem with a different unit of configuration. jenv is Java-only and works by writing shims and setting JAVA_HOME, so it does not cover non-Java kits at all. asdf is plugin-based and generalises to many runtimes, with versions declared per project directory through its own config file. SDKMAN! CLI sits between them: it covers multiple Candidates, but it is a Unix shell tool tied to its own install location and an .sdkmanrc, and its command layer is being rewritten in Rust. If your requirement is one runtime and you want the smallest possible surface, jenv is less machinery. If you want one manager for every runtime in a polyglot repo, asdf's plugin model is the broader fit. SDKMAN! CLI is the reasonable pick when the kits you switch are the ones it already publishes and you want the switching to happen in the shell.

Licence, packaging and the cost of upgrading

The project is Apache-2.0, which permits commercial and private use and modification, with the usual requirements around notices and attribution; the LICENSE file at the repository root is the authoritative text, and this is not legal advice. On cost, the practical question is not the licence but the migration. The README states that this project will eventually form a lightweight wrapper or launcher for the replacement Rust commands, so the upgrade path runs through sdkman-cli-native rather than through new features here. The repository also ships a Dockerfile based on openjdk:11 that installs zip, copies the tree into /usr/src/app and sets ./gradlew as the entrypoint, which is how the project builds and tests itself in a container. Note the version skew: the Dockerfile pins JDK 11, while the README tells developers to obtain JDK 11 with sdk env install, so both the build and the development instructions assume an 11-era toolchain.

What to check before you standardise on it

Read the .sdkmanrc in the repository you plan to build. It is the file the env commands consume, and it is the contract between your project and whatever SDKMAN installs. Then confirm the candidate and the exact version you need are published, because the README does not promise a fallback when a version is missing. If your team is on Windows, stop here: the README scopes the tool to Unix-based systems. If your team needs new commands rather than bug fixes, the README's notice tells you where those will land, and it is not this repository. The remaining case, Unix teams switching among published kits, is the one this project was built for and still handles.

Editorial conclusion

Use SDKMAN! CLI if you work on Unix, juggle several JDK versions, and want version switching in the shell rather than in a project file. Do not adopt it if you are on Windows, or if you expect new features: the README states that only bug fixes to supporting code are accepted and that commands will be phased out in favour of the Rust project. Before committing, check the .sdkmanrc in your repo and confirm the candidate and version you need are published, since the README does not document rollback of a failed install.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sdkman/sdkman-cli on GitHub