Джавист Роман ☕️

So true. Проверено на себе, обе верхние ветки 🙂

jenv и три места, где живёт версия Java (часть 4) Практический вывод: чем закрывать каждый из трёх Собираю всё вместе. 1. Терминал — jenv (или SDKMAN!, или что тебе ближе). Обязательно с jenv enable-plugin export, иначе первый пункт ты не закрыл, а только думаешь, что закрыл. 2. Сборка — toolchains в Gradle или Maven, зафиксированные в проекте. Единственное место, где версия принуждается, и вот почему: требование к JDK лежит в закоммиченном скрипте сборки, а билд-тул проверяет его сам, до компиляции. Не нашёл подходящую — падает: Gradle пишет No matching toolchains found for requested specification, Maven — Cannot find matching toolchain definitions. Собраться на случайной Java он в этом случае не может. .java-version и SDK в IDEA так не умеют — там договорённость, которую можно молча не соблюсти, и никто ничего не скажет. 3. IDE — Project Structure → SDK, руками, и следить, чтобы совпадало. Автоматизации тут я не нашёл. Проверка, что всё сошлось, — три команды подряд, тридцать секунд: jenv which java # что реально запустится в терминале echo $JAVA_HOME # что из этого увидят mvn и gradle mvn -version # или ./gradlew -version — чем собирается И последним шагом — глазами в Project Structure. Да, глазами. Ничего лучше я пока не нашёл. Вместо вывода Серебряной пули не вышло. Вышел узкий инструмент, который честно делает свою треть работы, — при условии, что ты знаешь про `export`-плагин и не ждёшь, что он поставит тебе Java. А самое ценное для меня оказалось не в утилите, а в том, что она заставила меня разложить по полочкам вещь, которой я много лет пользовался на автомате. Погружение в технику до руды, так сказать. Всем добра!

jenv и три места, где живёт версия Java (часть 3) jenv или SDKMAN! Раз уж мы про выбор — рядом стоит [SDKMAN!](https://sdkman.io/), и это первое, что мне скажут в комментариях. Разложу честно. 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 за тебя не скачает — установи руками и пропиши <jdkHome>. Так что «зафиксировали версию в репе» в мавеновском случае получается наполовину. продолжение ниже

jenv и три места, где живёт версия Java (часть 2) Три уровня приоритета — и грабля вторая Разобравшись с export, я полез настраивать проекты. Здесь всё логично, но знать надо заранее. Уровней три, приоритет такой: `shell` > `local` > `global`. Команда — Область — Приоритет jenv global <версия> — вся система, умолчание — низкий jenv local <версия> — текущий каталог, пишет .java-version — средний jenv shell <версия> — текущая сессия терминала — высокий И вот вторая грабля, на которой спотыкаются все: `jenv local` не меняет версию в уже открытой сессии. Ты стоишь в каталоге, выполнил jenv local 17.0.8, набираешь java -version — а там прежняя. Классическое «я же настроил, почему не работает». Для текущей сессии нужен jenv shell. Грабля третья: он молчит Самая неприятная из трёх. Если в .java-version записана версия, которой нет в jenv versions, jenv её просто игнорирует. Не ругается. Не предупреждает и не подсказывает, что версию надо сначала добавить через jenv add. Ты уверен, что репозиторий сам всё настроил. Он не настроил ничего. Мне такое поведение не нравится — лучше бы падал. Поэтому сверяй .java-version со списком jenv versions руками: сам jenv о расхождении не скажет. Диагностика, если что-то не сходится: jenv doctor и jenv which java — покажет, какой бинарник реально дёргается. Зачем `.java-version` в git Это, пожалуй, лучшее, что jenv даёт команде. Версия перестаёт быть знанием в чьей-то голове и становится частью репозитория. Новый человек делает git clone и получает версию вместе с кодом. Пара практических деталей: — В файле может быть номер (`17.0.8`) или имя из jenv versions (`openjdk-17.0.8`). Второе стабильнее. — Оговорка честная: это конвенция, а не принуждение. Работает при условии «у коллеги стоит jenv и нужная JDK». У коллеги без jenv это просто текстовый файлик в корне, который ничего не делает. Узел: три места, где живёт версия Java Когда я закончил разбираться с JAVA_HOME, до меня дошло, что «версия Java на проекте» — это три разных настройки: 1. Что запускается, когда ты набираешь `java` в терминале. Скрипты, jshell, разовые прогоны, утилиты. 2. Чем собирается проект. JDK, на которой стартуют mvn и gradle, — а если в проекте настроены toolchains, то ещё и отдельная JDK, которой компилируется код. 3. Чем компилирует IDE. Project Structure → SDK. Со вторым пунктом я сам сначала запутался, поэтому проговорю отдельно. Плагин export его частично закрывает: он выставляет JAVA_HOME, а от JAVA_HOME стартуют и Maven, и Gradle. Пока toolchains в проекте нет, эта же JDK код и компилирует — переключил версию через jenv, поменялась и сборка. Связь рвётся в тот момент, когда toolchains появились. Дальше компилятор выбирается по правилам toolchain-резолвинга, и JAVA_HOME на него уже не влияет: за ним остаётся только вопрос, на какой JVM запустился сам билд-тул. В документации Gradle это разведено прямым текстом, к ней вернусь ниже. То есть export закрывает второй пункт ровно до первого проекта с toolchains, а дальше перестаёт. Между тремя пунктами нет никакой связи. Никто не сверяет их между собой, ошибки не будет — всё просто работает по-разному в трёх местах. А наружу это вылезает самой дорогой фразой в командной разработке: «у меня собирается, у тебя нет». jenv закрывает пункт первый и только его. Продавать его как решение «проблемы версий Java» — врать, поэтому и не получается написать про него простой гайд «поставь и пользуйся». продолжение ниже

No text

200млрд параметров… дайте два!

Shadow AI — почему инженеры скрывают, что пользуются ИИ Доброго дня, инженеры и те, кто инженеров ведёт. Слушал подкаст Code of Leadership, выпуск про AI-assisted engineering. Полтора часа про то, как правильно встроить ИИ в разработку: копайлоты, MCP, метрики, место ИИ в SDLC. Разговор хороший, по делу. И где-то в середине проскочил термин, за который я зацепился и с которым хожу уже неделю — shadow AI. Проскочил сноской, в ряду прочих ИБ-рисков, между утечками и комплаенсом. А я на этой сноске завис. Потому что мне кажется, что она интереснее основного разговора. Полный текст — в файле ниже.

Самая сложная задача в разработке не писать код, а назвать его 😁 ...или сказ о том, как я час сижу придумываю новое название сервиса так, чтобы оно и смысл имело и чтобы не конфликтовало с названиями других сервисов...

sad story... #ai

No text