jenv и три места, где живёт версия Java (часть 3)

jenv или SDKMAN!

Раз уж мы про выбор — рядом стоит SDKMAN!, и это первое, что мне скажут в комментариях. Разложу честно.

jenv

Плюсы: — Узкий и предсказуемый, делает одну вещь. — .java-version на проект, коммитится в репозиторий. — Shim-ы и три уровня приоритета — механика простая, её видно насквозь. — Не лезет туда, куда не просили.

Минусы: — Не ставит JDK. — JAVA_HOME — только через плагин, и об этом надо догадаться. — Молчит на неизвестной версии. — Документация на сайте отставала от README.

SDKMAN!

Плюсы: — Ставит SDK сам, одной командой. — Не только JDK: Maven, Gradle, Kotlin, Scala, Groovy. — Живёт с 2012 года, вырос из GVM — Groovy enVironment Manager. Зрелость.

Минусы: — Берёт на себя больше, чем «переключалка версий». — Своя инфраструктура дистрибутивов, в которую надо вписаться.

Я пришёл к jenv случайно и остался — мне хватает узкой утилиты, а ставить JDK руками меня не раздражает. Если раздражает тебя — бери SDKMAN!, спорить не буду.

Есть ещё mise и asdf — универсальные менеджеры, один инструмент на все языки сразу. Я их не щупал, поэтому оценивать не берусь, просто знай, что они есть.

Кстати, про «а он вообще живой»: у jenv ~6,6k звёзд на GitHub, последний релиз 0.6.0 вышел 5 декабря 2025 года.

«А зачем всё это, если есть toolchains?»

Справедливый вопрос, и он самый частый. Отвечаю: это другой слой.

Toolchains отвечают на вопрос «чем собирать проект», а jenv — на вопрос «что у меня в терминале». В Gradle это разведено прямо в документации: JDK, на которой работает сам Gradle, и JDK, которой компилируется код, — две разные вещи. Появились toolchains в Gradle 6.7.

Больше того, Gradle умеет скачать JDK сам — auto-provisioning через toolchain resolver plugins, типовой пример это Foojay Toolchains Plugin. Ограничение: качает только GA-релизы, early access не качает.

Следствие: если у тебя Gradle с настроенными toolchains, версия сборки уже зафиксирована в репозитории и от твоей локальной переключалки не зависит вообще. Менеджер версий тебе нужен для другого — для того, что ты набираешь руками.

А что у Maven? Механизм есть, но устроен иначе, и я бы не сказал, что он закрывает вопрос так же плотно. Требования пишутся в pom.xml через maven-toolchains-plugin, а пути к JDK лежат в toolchains.xml — по умолчанию в ~/.m2/. То есть на машине, а не в репозитории: файл машинно-зависимый и не коммитится. И JDK Maven за тебя не скачает — установи руками и пропиши . Так что «зафиксировали версию в репе» в мавеновском случае получается наполовину.

продолжение ниже