JDK 26: HTTP/3, AOT-кешування і суворіші final-поля

JDK 26 розвиває Java одразу у двох напрямах: додає практичну підтримку HTTP/3 та вдосконалює запуск застосунків за допомогою AOT-кешування, водночас готуючи екосистему до суворішого трактування final-полів. Для команд, які працюють із production-сервісами, це не «оновлення заради номера», а привід окремо перевірити мережевий стек, фреймворки, агенти спостережуваності та сценарії серіалізації.

Що входить до JDK 26

До набору JEP для JDK 26 увійшли HTTP/3 для стандартного HTTP Client API, AOT Object Caching із будь-яким збирачем сміття, оптимізація пропускної здатності G1, видалення Applet API та підготовка до правила «final означає final». Окремі можливості залишаються preview або incubator: Structured Concurrency, Lazy Constants, PEM Encodings, Vector API та примітивні типи у patterns і switch. Це важливе розмежування: preview-функції не слід непомітно перетворювати на обов’язкову основу production-коду.

HTTP/3 з’являється у стандартному клієнті

JEP 517 додає HTTP/3 до java.net.http.HttpClient. Протокол працює поверх QUIC і UDP, тому його поведінка в корпоративній мережі може відрізнятися від HTTP/2 поверх TCP. Клієнт має домовлятися із сервером про доступний протокол і за потреби використовувати сумісний варіант. Практична користь полягає не в гарантованому прискоренні кожного запиту, а в кращій поведінці за втрат пакетів та можливості уникати блокування незалежних потоків одним втраченим TCP-сегментом.

Перед увімкненням перевірте UDP-трафік через балансувальники, проксі, VPN і міжмережеві екрани. Для розуміння транспортного рівня стане в пригоді матеріал про HTTP Datagrams і Capsule Protocol, а під час оновлення серверного фреймворку — наш план міграції на Spring Boot 4.

AOT-кешування не замінює профілювання

Ahead-of-Time Object Caching розширює попередню роботу над швидшим стартом JVM. JDK може зберігати об’єкти, створені під час тренувального запуску, та повторно використовувати їх під час наступного старту. У JDK 26 механізм працює не лише з одним конкретним GC. Найбільший інтерес він становить для CLI-інструментів, функцій із частими cold start, масштабованих до нуля сервісів і великих застосунків із дорогим початковим завантаженням класів.

Кеш прив’язаний до фактичної конфігурації застосунку й середовища. Його необхідно створювати відтворювано, оновлювати разом із runtime та залежностями і не переносити між несумісними збірками. Вимірюйте не тільки час до запуску процесу, а й time-to-ready, споживання пам’яті та затримку перших реальних запитів.

«Final означає final» змінюватиме застарілі практики

JEP 500 готує розробників до майбутнього обмеження глибокої рефлексії, яка змінює вже ініціалізовані final-поля. У JDK 26 основний сигнал — попередження, а не миттєва заборона всіх старих сценаріїв. Проблеми найімовірніші у бібліотеках серіалізації, ORM, mocking-інструментах, dependency injection та агентів, які покладаються на неофіційні способи зміни стану об’єкта.

Не вимикайте попередження глобально. Спочатку знайдіть бібліотеку, що виконує операцію, перевірте її актуальну версію та підтримуваний API. Такий аудит зменшує технічний борг ще до того, як майбутній JDK зробить обмеження суворішим.

G1 зменшує зайву синхронізацію

JEP 522 спрямований на підвищення пропускної здатності G1 шляхом скорочення синхронізації між потоками застосунку. Це не обіцянка однакового приросту для всіх навантажень. Сервіси з великими heaps, високою частотою алокацій і суворими SLO можуть відреагувати інакше, ніж короткі batch-процеси. Порівнюйте pause time, allocation rate, CPU та tail latency на однаковому трафіку.

Applet API остаточно прибрано

Аплети давно не підтримуються сучасними браузерами, а API було позначено як застаріле для видалення. Проте компіляція старих навчальних, промислових або внутрішніх систем може все ще залежати від класів java.applet. Якщо такий код існує, JDK 26 має стати приводом відокремити його, зафіксувати старе середовище лише там, де це виправдано, та запланувати заміну.

Preview-функції потребують окремого рішення

Structured Concurrency у JDK 26 залишається шостою preview-ітерацією, а Vector API — одинадцятою incubator-версією. Їх можна досліджувати, але команда повинна усвідомлювати ризик зміни API. Виробничий код із --enable-preview вимагає тієї самої версії runtime, якою його було скомпільовано, що ускладнює підтримку бібліотек і платформ.

Практичний план оновлення

1. зафіксуйте поточні показники запуску, CPU, пам’яті, GC і затримок;
2. оновіть JDK у CI та зберіть проєкт із максимальними попередженнями;
3. перевірте reflection, serialization, Java agents і native libraries;
4. окремо протестуйте HTTP/3 у реальному мережевому маршруті;
5. створіть AOT-кеш у контрольованому середовищі та виміряйте користь;
6. не вмикайте preview-функції без зафіксованого власника й плану міграції;
7. розгортайте canary-групою з можливістю швидкого повернення до попереднього JDK.

Кому варто переходити першими

JDK 26 особливо цікавий платформним командам, які контролюють runtime, мережу й observability. Звичайному бізнес-застосунку немає потреби поспішати лише заради HTTP/3. Якщо проєкт залежить від LTS-циклу, варто спочатку оцінити політику постачальника JDK та підтримку фреймворків. Вдала міграція вимірюється стабільністю і спрощенням експлуатації, а не самим фактом нового номера.

Першоджерела: сторінка проєкту JDK 26 та JEP 517 про HTTP/3.