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

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

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

Но тестировать, пересобирать и выкатывать приложения, скорее всего, придётся чаще.

CPU и CSPU: в чём разница

CPU (Critical Patch Update) — это привычные квартальные обновления с накопленными исправлениями безопасности.

CSPU (Critical Security Patch Update) — промежуточный релиз для ситуаций, когда важное исправление нужно доставить пользователям раньше следующего квартального CPU.

Квартальные обновления никуда не исчезают. CSPU дополняют их и позволят быстрее закрывать приоритетные уязвимости.

В выпуске CSPU Oracle ориентируется на третий вторник месяца. По той же схеме, что и CPU. Пока подтверждено только 18 августа 2026 года. Информация о следующих релизах появится по мере перехода на новый график.

Почему квартальных обновлений уже недостаточно

Между обнаружением уязвимости и появлением рабочего эксплойта проходит всё меньше времени.

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

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

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

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

Поскольку CSPU не предназначены для крупных изменений API, новых возможностей языка или несовместимых функциональных нововведений, то основное изменение затронет цикл обновления приложения:

  1. Получить новую сборку JDK.

  2. Прогнать тесты.

  3. Проверить совместимость.

  4. Пересобрать артефакты или контейнеры.

  5. Развернуть обновление.

И делать это придётся чаще.

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

Для большинства современных приложений такие обновления проходят без особых проблем. Дополнительная проверка потребуется проектам, в которых используются:

  • старые библиотеки и фреймворки,

  • собственные Java-агенты,

  • JNI или JNA,

  • нестандартные криптографические провайдеры,

  • интеграции с устаревшими TLS-системами,

  • внутренние и недокументированные механизмы JDK.

Минимальный набор проверок — регрессионные и интеграционные тесты. Для высоконагруженных приложений полезно дополнительно сравнивать latency, потребление памяти, загрузку CPU и поведение сборщика мусора.

Обновления будут выходить чаще, и ручной процесс проверки начнёт отнимать больше времени.

CI/CD должен быть готов к новым версиям

Отдельно стоит проверить всё, что автоматически разбирает номера версий Java.

В JEP 322 версия JDK описывается в формате:

FEATURE.INTERIM.UPDATE.PATCH

Четвёртый компонент, PATCH, предназначен для экстренных исправлений. JEP также указывает, что сравнивать элементы версии нужно как числа, последовательно, а не как обычные строки.

Это может оказаться важно для внутренних скриптов, CI/CD, сканеров и систем инвентаризации. Особенно если они:

  • ожидают строго определённое количество компонентов в версии;

  • используют жёстко заданные регулярные выражения;

  • сравнивают версии как строки;

  • считают допустимыми только квартальные номера обновлений;

  • извлекают версию из вывода `java -version`;

  • принимают решения о допуске ПО по собственным правилам.

Например, при строковом сравнении версия 21.0.10 может ошибочно оказаться «старше» 21.0.9, потому что символ 1 сравнивается с 9 раньше, чем система понимает числовое значение компонента.

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

  • корректно ли определяется версия установленной Java;

  • поддерживается ли четвёртый компонент PATCH;

  • правильно ли сравниваются номера версий;

  • не привязаны ли политики к квартальному расписанию;

  • корректно ли новые сборки отображаются в отчётах и сканерах;

  • не блокируют ли внеплановые версии системы контроля и допуска.

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

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

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

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

Более частые security-релизы позволят быстрее получать важные исправления, соответственно, и обновляться придётся чаще.

Теперь вопрос не только в том, готовы ли вы обновлять Java. Вопрос в том, можете ли вы делать это регулярно, быстро и без ручного аврала.