Впервые опубликовано на InfoWorld, 5 октября 2026 г.
Каждый сентябрь с метрономической регулярностью выходит новая версия платформы Java. Один небольшой нюанс, касающийся сроков: первый релиз-кандидат JDK был задержан на две недели из-за выпуска первого критического обновления безопасности (Critical Security Patch Update — CSPU) для JDK. Необходимость выпуска CSPU является прямым следствием того, что модели ИИ, такие как Claude Mythos от Anthropic, стали намного лучше справляться с выявлением уязвимостей и разработкой эксплойтов. Если вы еще не пересмотрели свою стратегию применения патчей для JDK, вам непременно стоит это сделать.
Как обычно, новые функции в каждом релизе Java определяются в первую очередь набором предложений по улучшению JDK (JDK Enhancement Proposals, JEP). В JDK 27 нас ждет девять JEP, пять из которых представляют собой функции, продолжающие дорабатываться в рамках концепции предварительных функций (preview) и модулей инкубатора.
Начнем с них, поскольку эти изменения намеренно невелики.
Предварительные и инкубационные функции в JDK 27
JEP 537 возвращает векторное API для рекордно сотого — двенадцатого — инкубационного этапа. Дело не в том, что у API есть серьезные проблемы; просто оно является компонентом более крупного проекта Valhalla. Авторы API не хотят фиксировать его окончательный вариант до тех пор, пока Valhalla не будет реализован (подробнее о Valhalla ниже). Таким образом, по сравнению с версией из JDK 26 никаких изменений нет.
Структурированная конкурентность возвращается в рамках уже седьмого предварительного просмотра по JEP 533. Это часть более крупного проекта OpenJDK Project Loom, набора функций для повышения масштабируемости и надежности многопоточных приложений. В этом релизе изменения незначительны и затрагивают в основном интерфейс Joiner.
Ленивые константы (JEP 531) возвращаются для третьего предварительного просмотра. Идея этой функции заключается в отложенной инициализации и доверии со стороны JVM. Ленивые константы являются объектами, несущими данные, но JVM рассматривает их как истинные константы. Это позволяет применять те же оптимизации производительности, что и при объявлении поля как final. Однако по сравнению с полями final ленивые константы предоставляют разработчикам большую гибкость в отношении момента их инициализации. В этом релизе в API внесено всего три небольших изменения.
Одна из функций, представляющих для меня особый интерес — JEP 532: примитивные типы в паттернах, instanceof и switch. Я проводил сессию «Загадки Java» на конференциях и встречах JUG, что привело к некоторым интересным дискуссиям о том, как использовать эту функцию. В JDK 26 были ужесточены некоторые правила доминирования шаблонов в операторах switch, но в JDK 27 она поставляется без изменений.
Последняя предварительная функция в JDK 27 — JEP 538, кодировки PEM (Privacy-Enhanced Mail) для криптографических объектов, которая теперь находится на стадии третьего предварительного просмотра. Этот API кодирует и декодирует криптографические ключи, сертификаты и списки отзыва сертификатов между объектами и широко используемым форматом передачи PEM. Сюда входит ряд небольших изменений в API. Одно из них, привлекшее мое внимание, — изменение основного класса PEM с обычного объекта на record. Причиной этого стало добавление новых конструкторов, принимающих содержимое, закодированное в Base64, в виде массивов байтов.
Финальные функции в JDK 27
Перейдем к остальным функциям, все из которых являются финальными.
JEP 534 теперь включает компактные заголовки объектов по умолчанию. Хотя в JDK 25 компактные заголовки объектов были переведены в разряд финальных, для их включения во время выполнения требовался явный флаг командной строки. Будучи фундаментальным изменением в JVM, они теперь доказали свою стабильность и могут использоваться в конфигурации по умолчанию. Приносимая ими польза заключается в повышении производительности за счет снижения потребления кучи (в JEP упоминается сокращение пространства кучи на 22% и снижение использования ЦП на 8% для бенчмарка SPECjbb2015).
Еще одно интересное изменение — JEP 523, которое делает сборщик мусора G1 (GC) стандартным во всех ситуациях. Начиная с JDK 9, G1 был стандартным для серверных приложений, но последовательный сборщик (serial collector) оставался таковым в средах с ограниченными ресурсами (с одним процессором или менее 1792 МБ физической памяти). Более свежие доработки G1 позволяют ему работать не хуже последовательного сборщика в любых условиях. Я подозреваю, что на фоне этого изменения мы вскоре увидим устаревание последовательного сборщика и его удаление из OpenJDK.
Впечатляюще звучащая функция — JEP 527, постквантовый гибридный обмен ключами для TLS 1.3. Постквантовая криптография (PQC) относится к алгоритмам шифрования и цифровой подписи, разработанным с расчетом на сохранение безопасности при будущих атаках со стороны квантовых компьютеров. Текущие криптографические стандарты, такие как RSA и ECC (криптография на эллиптических кривых), опираются на математические задачи (например, разложение больших чисел на множители), на решение которых у стандартных компьютеров уходят тысячи лет. Квантовые компьютеры, выполняющие алгоритм Шора, способны решать эти задачи за часы или минуты. И хотя способные на это квантовые компьютеры пока недоступны широкой общественности, киберпреступники уже собирают зашифрованные данные в расчете на то, что в будущем смогут расшифровать их с помощью квантовых компьютеров. Этот JEP интегрирует устойчивые к квантовым угрозам алгоритмы в стандартный уровень веб-безопасности и сетевой безопасности Java (TLS 1.3).
Наконец, у нас есть JEP 536 — маскирование данных внутри процесса для JFR (Java Flight Recorder). Java Flight Recorder — это легковесный диагностический фреймворк, встроенный в JVM. Он записывает информацию о времени выполнения и приложении в виде событий с временными метками в файл записи. Записи JFR обычно включают события, фиксирующие аргументы командной строки, значения переменных окружения и системные свойства, что позволяет увидеть, как процесс был запущен и настроен. Эти события могут содержать конфиденциальные данные, такие как секреты в аргументах командной строки, токенах доступа в переменных окружения и пароли в системных свойствах. Теперь JFR будет маскировать эти данные до того, как они покинут пределы процесса, чтобы конфиденциальная информация не утекла. Какая именно информация подвергается маскированию, можно контролировать с помощью специальных аргументов командной строки.
Большие перемены в JDK 28
Итак, почему этот пост называется «Затишье перед бурей»?
Глядя на JEP в JDK 27, можно заметить относительное затишье в плане новых функций: в основном это инкрементальные изменения предварительных функций и несколько небольших дополнений.
Что приводит нас к следующему релизу, JDK 28. Несмотря на то, что JDK 27 только что вышел, у нас уже есть представление о некоторых JEP, которые войдут в JDK 28. На момент написания статьи в их число входят шесть JEP. Два из этих JEP вносят изменения, которые давно назревали и вызывают множество обсуждений.
Во-первых, в Java наконец появится JSON API — то, что входило в сферу интересов еще с момента появления JEP 128 в далёком 2018 году. Этот парсер исключительно строг и не предлагает никаких либеральных режимов (в отличие от других сторонних API, таких как Jackson и Gson). Нам еще предстоит узнать, какими будут отзывы сообщества на этот счет.
Во-вторых, существует JEP 541, который объявляет порт macOS/x64 устаревшим. В связи с переходом Apple на чипы M-класса на базе архитектуры Arm поддержка Intel-порта для компьютеров Mac будет прекращена.
Затем мы переходим к по-настоящему крупным новостям в JDK 28: первым реальным частям Project Valhalla. Для этого предусмотрено два JEP: JEP 401, описывающий объекты-значения, и JEP 539 (обратите внимание на разницу в номерах), касающийся строгой инициализации полей в JVM.
Я подожду, пока JDK 28 будет готов к релизу, прежде чем говорить об этом подробно, но для Java наступает захватывающее время, когда происходят большие перемены. Следите за новостями!
Часто задаваемые вопросы
Каковы основные изменения в JDK 27?
JDK 27 — это в основном инкрементальный релиз: пять из его девяти JEP продолжаются в качестве предварительных версий или инкубаторов, включая Vector API в его двенадцатом инкубаторе, структурированную конкерентность в седьмом превью и ленивые константы в третьем. Финальные функции включают компактные заголовки объектов по умолчанию (JEP 534), G1 в качестве сборщика мусора по умолчанию во всех средах (JEP 523), постквантовый гибридный обмен ключами для TLS 1.3 (JEP 527) и сокрытие данных внутри процессов в Java Flight Recorder (JEP 536). Azul Core включает сборки для Java 27, а также для каждой текущей LTS-версии.
Как компактные заголовки объектов и G1 по умолчанию влияют на производительность JDK?
В JEP 534, который делает компактные заголовки объектов стандартными в JDK 27, отмечается сокращение пространства кучи (heap) на 22% и снижение использования ЦП на 8% в бенчмарке SPECjbb2015. JEP 535 делает G1 сборщиком мусора по умолчанию во всех ситуациях; недавние изменения в G1 позволяют ему работать так же эффективно, как и последовательный сборщик (serial collector), даже в однопроцессорных средах или условиях нехватки памяти.
Как следует скорректировать стратегию применения патчей для JDK в целях более быстрой установки обновлений безопасности?
Первый релиз-кандидат JDK 27 был задержан на две недели из-за первого критического обновления патча безопасности для JDK, и Саймон Риттер (Simon Ritter) из Azul связывает необходимость таких обновлений с тем, что модели ИИ всё лучше находят уязвимости и создают эксплойты. Риттер советует командам, которые еще не пересмотрели свою стратегию установки патчей для JDK, заняться этим. Azul Core предоставляет ежеквартальные, ежемесячные и внеплановые обновления, содержащие только исправления безопасности, поэтому исправление уязвимости не нужно ждать вместе с полным обновлением.
Что появится в JDK 28?
На данный момент для JDK 28 запланировано шесть JEP. Они включают стандартный JSON API, который является строгим и не имеет мягких режимов, прекращение поддержки (deprecation) порта macOS/x64 (JEP 541), а также первые наработки Project Valhalla: объекты-значения (JEP 401) и строгую инициализацию полей в JVM (JEP 539). Саймон Риттер из Azul ожидает, что JDK 28 принесет поистине крупные новости.
