Java будут обновлять чаще: что изменится для разработчиков и компаний

20 июля компания Oracle объявила о переходе на более частые релизы обновлений безопасности Java. К привычным квартальным CPU (Critical Patch Update), которые выходят в январе, апреле, июле и октябре, добавятся промежуточные ежемесячные релизы — CSPU (Critical Security Patch Update).

Первое такое обновление Java запланировано на 18 августа 2026 года — между июльским и октябрьским CPU. В 2027 году Oracle собирается выпустить несколько таких обновлений. Компаниям, которые используют Java в промышленной эксплуатации, уже стоит проверить, готовы ли их процессы к более частому обновлению JDK.

Шестимесячный цикл функциональных релизов Java при этом не меняется. Новые ежемесячные релизы будут посвящены прежде всего безопасности и стабильности, а не развитию языка или добавлению API.

Что такое CSPU

Дополнительные промежуточные релизы получили название CSPU — Critical Security Patch Update. Их задача — быстрее доставлять исправления приоритетных уязвимостей, не дожидаясь следующего квартального релиза.

Квартальные CPU — Critical Patch Update никуда не исчезнут. Они сохранятся как основные накопительные обновления. CSPU станут промежуточными релизами для случаев, когда исправление желательно предоставить раньше.

Oracle ориентируется на третий вторник месяца — по той же логике, по которой сейчас выходят квартальные обновления. Пока подтвержден только Java CSPU на 18 августа 2026 года. Более подробное расписание Oracle обещает опубликовать по мере перехода на новый цикл.

Почему квартального графика стало недостаточно

Уязвимости сегодня находят и анализируют быстрее, чем несколько лет назад. Инструменты автоматического анализа и решения на базе ИИ помогают исследователям проверять большие объемы кода и быстрее готовить исправления.

Но теми же возможностями пользуются и злоумышленники. После публикации информации об уязвимости рабочий способ её эксплуатации может появиться за дни, а не за месяцы.

Поэтому важен не только сам факт обнаружения уязвимости, но и время, которое проходит до появления готовой и протестированной сборки JDK. Чем дольше пользователи ждут обновления, тем дольше их системы остаются под риском. Более частый цикл должен сократить это окно.

Что изменится для Java-разработчиков

В исходном коде приложений радикальных изменений не ожидается. CSPU не предназначены для выпуска новых функций Java или крупных изменений API.

Изменится другое: тестировать приложения на новых сборках JDK придется чаще.

Даже небольшое обновление безопасности может повлиять на TLS, обработку сертификатов, криптографические алгоритмы, сетевые протоколы, XML, сериализацию, работу с изображениями или список доверенных центров сертификации. Иногда обновления также ужесточают ограничения для устаревших алгоритмов и небезопасных конфигураций.

Для большинства современных приложений переход на новую сборку пройдет незаметно. Больше внимания потребуется системам, которые используют старые библиотеки, собственные Java-агенты, JNI или JNA, нестандартную криптографию либо зависят от внутренних механизмов JDK.

Поэтому обновленную JDK по-прежнему нужно сначала проверять на тестовом контуре. Минимальный набор — регрессионные и интеграционные тесты. Для высоконагруженных систем стоит также контролировать производительность, потребление памяти и поведение сборщика мусора.

Приложения со встроенной JDK потребуют особого внимания

Во многих продуктах Java поставляется вместе с приложением. В таком случае обновление системной JDK на сервере не поможет: приложение продолжит запускаться на собственной, встроенной среде исполнения.

Производителям такого ПО придется чаще обновлять JDK или JRE внутри дистрибутива, пересобирать продукт, проводить тестирование и выпускать новую версию для пользователей.

Та же логика действует в контейнерной среде. Обновление Java на узле Kubernetes или виртуальной машине не меняет содержимое уже собранного образа. Чтобы закрыть уязвимость, нужно обновить базовый образ, пересобрать приложение и развернуть новую версию контейнера.

Именно поэтому более частый цикл затронет не только эксплуатацию, но и весь процесс сборки и доставки Java-приложений.

Почему стоит проверить обработку номеров версий

Обратите внимание на схему версионирования JDK, определённую в JEP 322. В этом JEP предусмотрен специальный счётчик для экстренных обновлений, выпущенных вне обычного релизного цикла.

Это важно для компаний, у которых номера версий Java автоматически обрабатываются в CI/CD, сканерах или внутренних политиках допуска ПО.

Проблема может возникнуть, если скрипт ожидает строго определённый формат версии, сравнивает номера как обычные строки или предполагает, что новые patch-релизы появляются только по квартальному графику.

Перед переходом на более частые обновления стоит проверить:

• корректно ли CI/CD определяет версию Java;
• правильно ли системы сравнивают разные сборки JDK;
• нет ли жёстко заданных регулярных выражений под старый формат;
• принимают ли системы контроля внеплановые версии;
• корректно ли версии отображаются в инвентаризации и отчётах.

Это небольшая техническая деталь, но именно такие детали часто ломают автоматическое обновление.

Что изменится в Axiom JDK

Мы также будем адаптировать график выпусков к более частому циклу обновлений безопасности Java.

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

Наша задача — сократить время между появлением исправления и выпуском готовой сборки Axiom JDK, сохранив требования к стабильности и совместимости.

Мы будем учитывать новый график и выпускать обновления чаще, чтобы российские пользователи могли своевременно получать исправления безопасности для поддерживаемых Java-платформ.