コンテンツへスキップ
LatchkeyLatchkey home

jEnv vs SDKMAN: Java バージョンの管理

jEnv はすでにインストール済みの JDK 間を切り替えます。SDKMAN は JDK に加えて他の JVM ツールもインストール・管理します。

jEnv は薄いバージョン切り替えツールです。JDK は自分でインストールし(Homebrew、ベンダーパッケージ)、登録すると、jEnv が .java-version ファイルでプロジェクトごとに JAVA_HOME を設定します。SDKMAN はさらに進んで、多数のベンダーの JDK ディストリビューションをインストールし、Gradle、Maven、Kotlin などを1つのカタログから管理します。jEnv はミニマルで JDK をインストールする何かと組み合わせて使い、SDKMAN はオールインワンのインストーラ兼マネージャです。

jEnvSDKMAN
JDK のインストールしない(自分でインストール)する
JAVA_HOME の設定する、プロジェクトごとする
他の JVM ツールなしGradle、Maven、Kotlin など
設定ファイル.java-version標準ファイルなし
最適な用途既存 JDK の切り替えすべての JVM ツールのインストールと管理

CI では

CI では、JDK は通常 setup-java によって提供されるため、jEnv と SDKMAN はローカルのパリティの話が中心になります。jEnv はパッケージマネージャから JDK を取得しプロジェクトごとの切り替えだけを望む開発者に適し、SDKMAN は特定ベンダーの JDK と build ツールを1つのツールでインストールしたいチームに適します。いずれもローカルと CI の Java バージョンを揃えます。

高速化

固定したバージョンと lockfile をキーに、JDK のインストールと build ツールの cache を保存しましょう。どちらも CI runner 上で動作し、より高速なマネージド runner は JDK のセットアップと build の手順を短縮します。

Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"

What actually changes when you switch

  • Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
  • Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
  • CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
  • Everyone on the team and every runner must move together. Pin the version so they cannot drift.

結論

すでに別の方法で JDK をインストールしていて、プロジェクトごとの切り替えだけが必要なら jEnv。JDK ディストリビューションと JVM の build ツールをインストールする1つのツールがほしいなら SDKMAN。多くの JVM 開発者はインストールに SDKMAN を使い、別の切り替えツールを好む場合のみ jEnv 式の切り替えを使います。

よくある質問

jEnv vs SDKMAN: Managing Java Versions?
jEnv is a thin version switcher: you install JDKs yourself (Homebrew, vendor packages), register them, and jEnv sets JAVA_HOME per project via a .java-version file. SDKMAN goes further, installing JDK distributions from many vendors and managing Gradle, Maven, Kotlin, and more from one catalog.
In CI?
In CI, JDKs are usually provided by setup-java, making jEnv and SDKMAN more about local parity. jEnv suits developers who get JDKs from a package manager and just want per-project switching; SDKMAN suits teams that want one tool to install a specific vendor JDK plus build tools. Either keeps local and CI Java versions aligned.
Speed it up?
Cache the JDK install and the build-tool caches keyed on your version pins and lockfiles. Both run on CI runners; faster managed runners shorten the JDK setup and build steps.
Which should I choose?
Already installing JDKs another way and only needing per-project switching: jEnv. Wanting one tool to install JDK distributions and JVM build tools: SDKMAN. Many JVM developers use SDKMAN to install and jEnv-style switching only if they prefer a separate switcher.

関連ガイド