SDKMAN! CLI keeps parallel SDK versions on Unix while its commands head for Rust

The commands here are being phased out for a Rust rewrite

The README opens with a NOTICE rather than a feature list, and it is the most consequential thing on the page. Every SDKMAN! command is being rewritten in Rust under a separate project, sdkman-cli-native, which that page describes as supplementing this one. Until the rewrite lands, this repository accepts only bug fixes to supporting code, and no further enhancements to the commands themselves. The commands here will be phased out, and the end state is stated plainly: this project becomes a lightweight wrapper and launcher for the Rust replacements.

That settles what a new contributor should do here. Repairing a broken shell function is welcome. Extending the command set is not, because the destination for that work is named in the same paragraph.

One curl line, then the shell restart the installer asks for

Installation is a single pipeline into bash:

curl -s https://get.sdkman.io | bash

The installer inspects the environment rather than assuming a clean one. If something needs tweaking for SDKMAN to work, it prompts for that adjustment and then asks you to restart, which means a first run can look finished while the command is still missing from the current session. On a machine where the installer had to prompt, that restart is the step to confirm before debugging anything else.

Uninstallation and shell setup are documented on the SDKMAN! website. For CI, the installer supports non-interactive mode and an option not to modify shell configuration.

Candidates are installed, switched, removed and listed as parallel versions

The stated job is managing parallel versions of multiple software development kits on any Unix-based system, and the four verbs are installing, switching, removing and listing. The unit being managed is a candidate, one of the kits it manages in parallel versions, and the reason to use the tool at all is having several of them side by side and choosing between them.

The repository root carries a `.sdkmanrc` next to `build.gradle` and `settings.gradle`. The name says what it is for: a per-project version declaration checked in beside the code, which is a different thing from the shell-level switching the four verbs cover. Its contents and syntax never appear on this page, and the candidate names you can install are not listed either, so both come from the documentation site the README links rather than from here.

JDK 11 is the only kit the README names, and it installs itself

The tool claims to manage multiple kits on any Unix-based system, but the one concrete example anywhere in the README is Java. For development on the project itself the requirement is a JDK 11, and the route to it is SDKMAN itself:

sdk env install

The tool that builds the project is the tool the project distributes, which is tidy and also circular. A contributor with no JVM on the machine depends on the shell pipeline in the previous step working first. It also means the claim of kit independence rests on the documentation site rather than on examples here: no Gradle, Groovy, Kotlin, Maven or Node candidate is named, and the page says nothing about Windows, which is not a Unix-based system.

src/test/resources/features is where the CLI behaviour is written down

The BDD tests live under `src/test/resources/features` and are written in Cucumber, which means command behaviour is described in feature files rather than asserted in shell scripts. They run through Gradle:

./gradlew test

That is the only build instruction on the page besides the installer, and it is aimed at contributors rather than users. `build.gradle`, `settings.gradle`, `gradlew` and `gradle/` are all at the top level, so the wrapper ships with the project, but nothing here gives the Gradle version the wrapper pins or the JDK range the build accepts beyond the JDK 11 note. The feature files are the closest thing to an authoritative description of what each subcommand does.

The Dockerfile starts from openjdk:11 and runs the wrapper as its entrypoint

A Dockerfile sits at the repository root and is short enough to quote in full:

FROM openjdk:11

RUN apt-get update && \
  apt-get -y install zip

# Copy all here
RUN mkdir -p /usr/src/app
ADD . /usr/src/app
WORKDIR /usr/src/app

ENTRYPOINT ["./gradlew"]

The base image is JDK 11 again, matching the contributor requirement, and `zip` is installed before any source is copied. Why `zip` is needed is not said. The whole context lands in `/usr/src/app` and the entrypoint is the Gradle wrapper itself, so the image runs `./gradlew` with whatever arguments follow it. There is no exposed port and no second stage, and the README never mentions the file, so it reads as contributor tooling rather than a supported way to run SDKMAN in a container.

Three releases in 2026, one of them a moving beta tag

The release tags carry the same message as the notice. `5.23.2` shipped 2026-10-06, a tag called `latest`, labelled Beta release, moved on 2026-10-24, and `5.24.0` followed the same day as the last push to master. Numbered releases alongside a rolling beta tag as the branch moves is a project still shipping while the rewrite proceeds elsewhere.

For anyone pinning, `5.24.0` is the newest numbered version here, and `latest` is not something you can hold. The default branch is master, the licence is Apache-2.0, and the backend is hosted on DigitalOcean as a sponsored partner, which is a hosting fact rather than a code fact.

Editorial conclusion

Pick SDKMAN! if you want parallel versions of tools on a Unix-based machine and are willing to live with a shell function and a restart after installing. On Windows, use the documented WSL or Git Bash plus MinGW route; native Windows installation is not supported. If you intend to extend the command set, check the project's notice directing new commands to the Rust rewrite. Before adopting it inside a team, check what `sdkman-cli-native` already covers, since that project is the one meant to outlive the shell implementation, and use the documented non-interactive and optional no-profile-update installer settings in CI.

Frequently asked questions

Official sources

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