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

> Java における jEnv vs SDKMAN: すでにインストール済みの JDK の切り替えツールと、JDK と JVM ツールのインストーラ兼マネージャ。スコープと CI への適合を比較。

Source: https://latchkey.dev/ja/learn/tool-comparisons/jenv-vs-sdkman  
Updated: 2026-06-26

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

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

## Comparison

|  | jEnv | SDKMAN |
| --- | --- | --- |
| 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"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## 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 式の切り替えを使います。

## FAQ

### 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt