В JDK 26 есть JEP 500 — Prepare to Make Final Mean Final. Теперь JVM предупреждает о попытках изменить через deep reflection final-поле объекта, не объявленное как static. В одном из будущих релизов такие операции планируется запрещать, если владелец приложения не разрешил их явно. В статье разберём:

Представьте: в пятницу вечером руководитель уверенно сообщает, что переход со Spring Boot 3.5 на 4.0 будет простым и его можно закончить за выходные. Скорее всего, вы уточните, на чём основана такая оценка, и напомните о несовместимых изменениях.

Теперь заменим руководителя на GitHub Copilot или другую большую языковую модель (LLM). Она предлагает рефакторинг метода, новую зависимость или готовый шаблон реализации. Ответ выглядит аккуратно и звучит уверенно. Модель не предупреждает, что может ошибаться. Возникает вопрос: проверяем ли мы такой код столь же строго, как заявление руководителя, или сразу принимаем его?

По данным отчёта Sonatype за 2026 год, 27,76% из 36 870 сгенерированных LLM рекомендаций по обновлению зависимостей ссылались на несуществующие версии этих зависимостей. Получается, одна из трёх-четырёх зависимостей — выдуманная. И проблема не ограничивается зависимостями: та же ложная уверенность может присутствовать в любой строке кода, созданной ИИ.

Недавно я разбирал истории CVE, связанные с завершением поддержки Tomcat 8.5, и решил посмотреть на Spring Boot 3.5. Я задался тем же вопросом применительно к Spring Boot: что происходит с уровнем защищённости приложения, когда используемая версия достигает End Of Life (EOL)?