Привычный график обновлений Java меняется. Теперь к релизам в январе, апреле, июле и октябре Oracle планирует добавить промежуточные релизы — CSPU (Critical Security Patch Update), чтобы не откладывать исправление критичных уязвимостей до следующего квартала.
Первый такой релиз запланирован на 18 августа 2026 года — между июльским и октябрьским CPU. В 2027 году Oracle хочетвыпустить несколько таких ежемесячных обновлений и заранее рекомендует компаниям подготовиться к новому графику.
Для разработчиков это не означает, что новые языковые возможности или API начнут появляться каждый месяц. Шестимесячный цикл функциональных релизов Java не изменится. CSPU будут содержать прежде всего исправления безопасности и стабильности.
Но тестировать, пересобирать и выкатывать приложения, скорее всего, придётся чаще.
CPU и CSPU: в чём разница
CPU (Critical Patch Update) — это привычные квартальные обновления. Они выходят по расписанию и содержат накопленные исправления безопасности.
CSPU (Critical Security Patch Update) — промежуточный релиз для ситуаций, когда важное исправление желательно доставить пользователям раньше, не дожидаясь следующего квартального CPU.
Квартальные обновления никуда не исчезают. CSPU дополняют их и позволяют быстрее закрывать приоритетные уязвимости.
Oracle ориентируется на третий вторник месяца — по той же схеме, по которой выпускаются CPU. Пока для Java подтверждена только одна конкретная дата: 18 августа 2026 года. Информация о следующих релизах будет публиковаться по мере перехода на новый график.
Почему квартальных обновлений уже недостаточно
Между обнаружением уязвимости и появлением рабочего эксплойта проходит всё меньше времени.
Автоматический анализ кода и разные инструменты на базе ИИ помогают быстрее находить ошибки, проверять большие кодовые базы и готовить исправления. Но те же технологии доступны не только специалистам по безопасности, но и злоумышленникам для более быстрого анализа уязвимостей и создания способов их эксплуатации.
В результате квартальный цикл иногда оставляет слишком большое окно между готовностью исправления и выпуском официальной сборки JDK.
Переход к более частым обновлениям должен сократить это окно. Если исправление критично, его можно будет выпустить в ближайший месячный CSPU, а не держать до следующего CPU.
Что изменится для разработчиков
На уровне исходного кода — скорее всего, немногое. CSPU не предназначены для крупных изменений API, новых возможностей языка или несовместимых функциональных нововведений.
Основное изменение затронет цикл обновления приложения:
-
получить новую сборку JDK;
-
прогнать тесты;
-
проверить совместимость;
-
пересобрать артефакты или контейнеры;
-
развернуть обновление.
И делать это придётся чаще.
Даже небольшой security-релиз может менять поведение компонентов, связанных с TLS, сертификатами, криптографией, сетевыми протоколами, XML, сериализацией или обработкой изображений. В обновлениях также могут отключаться устаревшие алгоритмы, изменяться наборы доверенных корневых сертификатов или ужесточаться небезопасные настройки.
Для большинства современных приложений такие обновления проходят без заметных проблем. Но дополнительная проверка потребуется проектам, в которых используются:
-
старые библиотеки и фреймворки;
-
собственные Java-агенты;
-
JNI или JNA;
-
нестандартные криптографические провайдеры;
-
интеграции с устаревшими TLS-системами;
-
внутренние и недокументированные механизмы JDK.
Минимальный набор проверок — регрессионные и интеграционные тесты. Для высоконагруженных приложений полезно дополнительно сравнивать latency, потребление памяти, загрузку CPU и поведение сборщика мусора.
Не потому, что каждый CSPU обязательно что-нибудь сломает. Просто обновления будут выходить чаще, а значит, ручной процесс проверки начнёт отнимать больше времени.
Встроенная JDK усложняет обновление
В большинстве Java-продуктов среда исполнения поставляется вместе с приложением. Это удобно: пользователю не нужно отдельно устанавливать и настраивать Java, а разработчик контролирует версию JDK.
Но с точки зрения безопасности есть важный нюанс. Обновление системной Java на сервере ничего не изменит, если приложение запускается на собственной JDK из каталога дистрибутива.
Поставщику такого продукта придётся:
-
заменить встроенную JDK или JRE;
-
пересобрать приложение;
-
провести тестирование;
-
подготовить новый дистрибутив;
-
доставить обновление пользователям.
При более частом выходе патчей этот цикл тоже придётся запускать чаще.
То же самое относится к контейнерам. Обновление Java на Kubernetes-узле или виртуальной машине не обновляет JDK внутри уже собранного образа. Чтобы исправление попало в приложение, нужно обновить базовый образ, заново собрать контейнер и развернуть его.
Новый график повлияет на весь конвейер поставки: от обновления зависимостей и базовых образов до тестирования, релиза и развёртывания.
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 и не новый цикл развития языка. Но для команд, которые отвечают за сборку, тестирование и эксплуатацию приложений, график работы заметно изменится.
Теперь вопрос не только в том, готовы ли вы обновлять Java. Вопрос в том, можете ли вы делать это регулярно, быстро и без ручного аврала.
ссылка на оригинал статьи https://habr.com/ru/articles/1065922/