Java SE 26 отнесён к категории выпусков с обычным сроком поддержки, обновления для которого будут выпускаться до следующего релиза. В качестве ветки с длительным сроком поддержки (LTS) следует использовать Java SE 25, Java SE 21 или Java SE 17, обновления для которых будут выпускаться до 2033, 2031 и 2029 годов соответственно (общедоступные — до сентября 2030, 2028 и 2026 годов). Расширенная поддержка LTS-ветки Java SE 8 продлится до 2030 года, а Java SE 11 — до 2032 года.
Среди изменений в Java SE 26 (1, 2, 3, 4):
- Реализован вывод предупреждения при использовании глубокой рефлексии для изменения полей, помеченных ключевым словом «final». В будущем планируется отключить по умолчанию небезопасные возможности языка и, среди прочего, сделать поля, помеченные как final, полностью не изменяемые, убрав обходной путь для их изменения через глубокую рефлексию (API Reflection).
- Удалён API Applet (java.applet.Applet*, javax.swing.JApplet), применявшийся для запуска Java-приложений в браузере. Данный API потерял актуальность после прекращения поддержка Java-плагина для браузеров и был объявлен устаревшим в 2021 году.
- Реализована возможность использования предварительно формируемого кэша (AOT — ahead-of-time) c любыми сборщиками мусора, включая ZGC (Z Garbage Collector). Изменение подразумевает поддержку последовательной загрузки прокэшированных Java-объектов в память, используя универсальный и не зависящий от сборщиков мусора формат вместо прямого маппинга в память специфичных представлений кэша. Использование AOT-кэша сокращает время запуска и ускоряет актуализацию (warmup) виртуальной машины HotSpot.
- В API HTTP Client добавлена поддержка протокола HTTP/3, позволяющая приложениям и библиотекам обращаться к серверам по HTTP/3 после минимальных изменений кода.
- Повышена производительность сборщика мусора G1, благодаря сокращению блокировок для синхронизации потоков приложения с потоками сборщика мусора.
- Предложен второй предварительный вариант API для кодирования и декодирования объектов с криптографическими ключами, сертификатами и списками отозванных сертификатов, используя формат PEM (Pivacy-Enhanced Mail).
- Предложен для тестирования шестой предварительный вариант API для cтруктурированного параллелизма (Structured Concurrency), упрощающего разработку многопоточных приложений за счёт обработки нескольких задач, выполняемых в разных потоках, как единого блока.
- Добавлен вторая предварительная редакция API Lazy Constants для работы с объектами, содержащими неизменяемые данные и обрабатываемыми в JVM как константы. К подобным объектам применяются оптимизации производительности, аналогичные полям с ключевым словом «final». В отличие от «final» новый API разделяет создание постоянных значений и их инициализацию, гарантирует, что значение может быть инициализировано только один раз, сокращает время запуска программ и позволяет применять в пользовательском коде оптимизации сворачивания констант (constant-folding), ранее использовавшиеся только во внутреннем коде JDK.
class Application { // Было: // static final UserService USERS = new UserService(); // Теперь можно: static final StableValue‹UserService› USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } } - В механизме сопоставления с образцом предложен четвёртый предварительный вариант возможности использования примитивных типов (int, byte, char и другие базовые типы, не являющиеся объектами) во всех видах шаблонов, в операторе «instanceof» и в блоках «switch».
switch (x.getStatus()) { case 0 -› "okay"; case 1 -› "warning"; case 2 -› "error"; case int i -› "unknown status: " + i; } if (i instanceof byte b) { ... b ... } - Предложена одиннадцатая тестовая реализация API Vector, предоставляющего функции для векторных вычислений, которые выполняются с использованием векторных инструкций процессоров x86_64 и AArch64 и позволяют одновременно применить операции сразу к нескольким значениям (SIMD). В отличие от предоставляемых в JIT-компиляторе HotSpot возможностей по автовекторизации скалярных операций, новый API даёт возможность явно управлять векторизацией для параллельной обработки данных.
Кроме того, компания Oracle анонсировала проект Detroit, который будет развиваться в составе OpenJDK и нацелен на улучшение переносимости между Java, JavaScript и Python. В рамках проекта намерены предоставить возможность встраивания в процесс JVM runtime с JavaScript-движком V8 и интерпретатором CPython. Ранее компания Oracle уже развивала JavaScript-движок Nashorn, работающий поверх виртуальной машины JVM, но свернула проект из-за проблематичности разрабатывать отдельную реализацию JavaScript в условиях, когда основная экосистема завязана на движке V8.
Дополнительно можно отметить публикацию обновления платформы для создания приложений с графическим интерфейсом JavaFX 26. В ближайшие часы также ожидается выпуск универсальной виртуальной машины GraalVM 26, поддерживающей запуск приложений на JavaScript (Node.js), Python, Ruby, R, любых языках для JVM (Java, Scala, Clojure, Kotlin) и языках, для которых может формироваться биткод LLVM (C, C++, Rust).
Источник: http://www.opennet.ru/opennews/art.shtml?num=65009