# Нововведения Java 26

Java не стоит на месте и продолжает активно развиваться\. Вышла уже 26 версия языка\. В этом релизе реализовали множество фич, направленных на оптимизацию выполнения Java приложений, а также в нём отказались от поддержки апплетов\. Обо всех этих и других нововведениях расскажем в статье\.

![1370_java26_ru/image1.png](https://import.viva64.com/docx/blog/1370_java26_ru/image1.png)

На данный момент каждая новая версия Java выходит раз в полгода\. И поскольку [релиз Java 25 вышел](https://pvs-studio.ru/ru/blog/posts/java/1284/) в сентябре 2025 года, в марте 2026 настало время для выхода Java 26\.

Java 25 была LTS релизом, эта же версия на долгосрочную поддержку не рассчитана\. И изменений она принесла не так много, как предыдущая\. Но их немногочисленность не отменяет того, что новая версия несёт с собой важные для языка моменты\. В конце концов, не в количестве же дело :\)

Итак, давайте посмотрим на основные нововведения, появившиеся в Java 26\.

## JEP 500 Prepare to Make Final Mean Final

[Ссылка на JEP](https://openjdk.org/jeps/500)\.

Достаточно интересное и забавное название\. А что конкретно это значит? Нужно совсем немного предыстории\.

Начиная с JDK 5, появилась возможность с помощью рефлексии изменять значение `final` полей \(`java.lang.reflect.Field#setAccessible` и `java.lang.reflect.Field#set`\)\. Что, возможно, хорошо для тех, кому это нужно \(часто ли вы изменяете `final` поля?\), но плохо с двух других точек зрения:

1. Когда работаешь с `final` полем, ожидаешь, что примитивный объект после инициализации никогда не изменится\. В данном случае, за счёт подобных возможностей, мы имеем дело с некоторой неконсистентностью описания и реализации\.
1. Невозможность провести оптимизации с `final` полями\. Тот же самый [constant folding](https://en.wikipedia.org/wiki/Constant_folding) невозможен, если мы не уверены, что значение/выражение в константе не меняется\.

Чтобы убрать неконсистентность и добавить возможность оптимизировать всё, что связано с `final` полями, начиная с этого JEP\-а, у разработчика постепенно будут забирать возможность их изменять\. А за счёт чего?

Конкретно в Java 26 при изменении значения `final` JVM будет выдавать специальные предупреждения\. В следующих версиях при попытке изменить `final` поле будет возникать исключение\.

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

## JEP 504 Remove the Applet API

[Ссылка на JEP](https://openjdk.org/jeps/504)\.

Эпопея, которая длилась 9 лет, подходит к завершению\. Да, с этого момента апплеты больше недоступны\.

Как выглядела вся хронология удаления апплетов:

1. 2017 год \([JEP 289](https://openjdk.org/jeps/289), JDK 9\) — апплеты помечаются как `Deprecated`, поскольку браузеры отказываются от их поддержки\.
1. 2018 год \(JDK 11\) — Аppletviewer, который позволял тестировать апплеты без браузера, [удалён](https://bugs.openjdk.org/browse/JDK-8200549)\. Как следствие, возможности тестировать апплеты с помощью JDK не стало\.
1. 2020 год \([JEP 398](https://openjdk.org/jeps/398), JDK 17\) — апплет API отмечено `forRemoval=true`;
1. 2024 год \([JEP 486](https://openjdk.org/jeps/486), JDK 24\) — удаляют `SecurityManager`, чьё предназначение как раз и заключалось в том, чтобы контролировать безопасность при исполнении апплетов\.

И сейчас, в 2026 году, спустя 9 лет после начала действий по удалению Applet API, вся эта чреда дошла до своего логического конца\! 

А ведь им не было и 33 лет\.\.\. Легенды умирают молодыми и при жизни непонятыми\.

## JEP 517 HTTP/3

[Ссылка на JEP](https://openjdk.org/jeps/517)\.

В Java 11 [появился `HttpClient`](https://pvs-studio.ru/ru/blog/posts/java/1337/#IDB3E97262DA), который пришёл на замену устаревшему [`HttpUrlConnection`](https://docs.oracle.com/javase/8/docs/api/java/net/HttpURLConnection.html)\. Он работает с HTTP\-запросами, используя версии протоколов HTTP/1\.1 и HTTP/2\. В 2022 году был стандартизирован протокол HTTP/3\. И на данный момент [по статистике от W3Techs](https://w3techs.com/technologies/details/ce-http3) более трети веб\-серверов поддерживают эту версию протокола\. 

Поэтому момент настал, и в рамках этого JEP\-а в `HttpClient` добавили поддержку работы с запросами по протоколу HTTP/3\. 

Для того, чтобы запросы от клиента отправлялись по протоколу третьей версии, необходимо при конфигурации `HttpClient` явно выставить соответствующий флаг:

```cpp
var client = HttpClient.newBuilder()
                       .version(HttpClient.Version.HTTP_3) // <=
                       .build();
```

Либо при конфигурации самого запроса сделать то же самое:

```cpp
var request = HttpRequest.newBuilder(URI.create("https://openjdk.org/"))
                         .version(HttpClient.Version.HTTP_3) // <=
                         .GET().build();
```

Но если целевой сервер не поддерживает эту версию протокола, запрос под капотом будет понижен сначала до версии HTTP/2, а потом, если нужно, до версии HTTP/1\.1\.

Среди преимуществ добавления HTTP/3 выделяют:

1. Более быстрые "рукопожатия"\.
1. Более надёжная передача данных\.
1. Решение проблемы с блокировкой начала очереди \([Head\-of\-line blocking](https://en.wikipedia.org/wiki/Head-of-line_blocking)\)\.

## JEP 526 Lazy Constants \(Second Preview\)

[Ссылка на JEP](https://openjdk.org/jeps/526)\.

Теперь переходим к preview\-фичам\. Этот JEP является логическим продолжением [JEP 502: Stable Values](https://openjdk.org/jeps/502)\. Кратко напомним, в чём заключается его суть\.

Эти изменения добавят API в Java, которое позволит определять ленивые константы\. Ведь сейчас статические константы инициализируются при загрузке класса, даже если они будут использоваться гораздо\-гораздо позже \(или вовсе не будут\)\. А это изменение добавит сущность, которая объединяет в себе константную неизменяемость и возможность инициализировать значения лениво — только в момент обращения\.

Из плюсов — оптимизация при запуске приложения и возможность оптимизировать эти значения так же, как и константные\.

В рамках этого второго превью мы имеем следующие изменения:

* Разрабатываемое API, как вы можете заметить, переименовано\. Было — `StableValue`, но его изменили на более высокоуровневое `LazyConstant`\.
* Некоторые низкоуровневые методы и фабрики были удалены\. Для пользователей остались только высокоуровневые фабрики, принимающие сами значения\.
* Для оптимизации удалена возможность работать с `null` значениями\.

## JEP 529 Vector API \(Eleventh Incubator\)

[Ссылка на JEP](https://openjdk.org/jeps/529)\.

Если вы забыли или не знали, что такое Vector API, сейчас мы вам кратко напомним\.

Vector API — это API, позволяющее в рамках Java осуществлять векторные вычисления на процессоре, обеспечивая параллелизм на уровне данных\. Цель — естественно, производительность в совокупности с удобством использования за счёт высокоуровневого API\.

<details>
   <summary>Векторные вычисления?</summary>

Векторные вычисления в процессорах — это способ выполнения операций над векторами данных с использованием архитектуры типа [SIMD \(Single Instruction, Multiple Data\)](https://ru.wikipedia.org/wiki/SIMD), при котором одна машинная инструкция применяется параллельно ко всем элементам вектора\.


</details>


В первую очередь нельзя не отметить забавность того факта, что этот JEP тянется в [инкубаторе](https://openjdk.org/jeps/11) 11\-ый раз\. Путём несложных математических вычислений становится понятно, что сама фича была впервые представлена в Java 16 \([JEP 338](https://openjdk.org/jeps/338)\)\. 

И конкретно в этом JEP, со слов самих авторов, никаких существенных изменений нет\. Эта функциональность ждёт релиза [Project Valhalla](https://openjdk.org/projects/valhalla/), и сразу после Vector API будет доступен в Preview\. Точной даты его релиза нет, но надеемся, что он выйдет как можно скорее\. Всё\-таки, что Vector API, что [Value Classes](https://openjdk.org/jeps/401) звучат как очень интересные и нишевые фичи\.

## JEP 530 Primitive Types in Patterns, instanceof, and switch \(Fourth Preview\)

[Ссылка на JEP](https://openjdk.org/jeps/530)\.

И мы переходим к последнему рассматриваемому JEP\. На рассмотрении 4\-ое превью фичи, позволяющей использовать примитивы в Pattern Matching конструкциях операторов `instanceof` и `switch`\.

Выглядеть это может так\. Оператор `switch` до этой фичи:

```cpp
switch (x.getStatus()) {
    case 0 -> "okay";
    case 1 -> "warning";
    case 2 -> "error";
    default -> "unknown status: " + x.getStatus();
}
```

Оператор `switch` после:

```cpp
switch (x.getStatus()) {
    case 0 -> "okay";
    case 1 -> "warning";
    case 2 -> "error";
    case int i -> "unknown status: " + i;
}
```

В рамках четвёртого превью этот JEP не предоставил нового API или возможностей, однако он уточнил и расширил поведение языка за счёт двух нововведений:

1. [**Safety of conversion**](https://openjdk.org/jeps/530#Safety-of-conversions) — формализация, описывающая возможные преобразования примитивных типов для Pattern Matching \(какие являются точными, а какие могут привести к потере данных либо же вообще являются некомпилируемыми\)\. 
1. [**Dominance**](https://openjdk.org/jeps/530#Dominance) — проверка уровня компиляции на то, не "перекрывает" ли одна ветка `case` другую\. Если перекрытие происходит, то начиная с Java 26 будет выдаваться ошибка компиляции\. Из\-за этого некоторые конструкции из Java 25 в Java 26 будут некомпилируемыми\.

Пример ныне некомпилируемых конструкций:

```cpp
byte x = ...;
switch (x) {
    case short s -> {}
    case 42      -> {}   // error: dominated since 42 can be
                         // converted unconditionally exactly to short
}
```

Или:

```cpp
int x = ...;
switch (x) {
    case int _      -> {}  // unconditional pattern
    case float _    -> {}  // error: dominated
}
```

## Итог

Сам по себе релиз Java 26 принёс не так много новых фич или API\. При этом в нём вышло достаточно большое количество различных правок, которые допиливали уже существующий функционал\. Корректировка `final`, `Lazy Constants` и всё остальное — продолжение тенденции на оптимизацию выполнения Java программ\. 

Круто, что Java не стоит на месте\. Оптимизации, доработка реализуемого API и всё остальное говорит нам о том, что Java живее всех живых и продолжает развиваться\. 

С оригинальным описанием всех изменений вы можете ознакомиться [здесь](https://openjdk.org/projects/jdk/26/)\. Если хотите прочитать наши предыдущие обзоры новых версий Java, вот их список:

* [Нововведения Java 25](https://pvs-studio.ru/ru/blog/posts/java/1284/);
* [Нововведения Java 24](https://pvs-studio.ru/ru/blog/posts/java/1233/)\.