JDK 18: Новые возможности в Java 18

В марте 2022 года в Java 18 появится векторный API, предварительное сопоставление шаблонов для операторов switch, набор символов по умолчанию UTF-8 и простой веб-сервер.

Выпуск Java Development Kit (JDK) 18 намечен на 22 марта 2022 года. В новой версии стандартной Java будет девять новых функций, причем набор функций был заморожен по состоянию на 9 декабря.

Релиз перешел в фазу начального обновления. Обновления стандартной Java выходят каждые шесть месяцев, последнее из них, JDK 17, появилось в сентябре.

На странице OpenJDK перечислены следующие функции, официально предназначенные для JDK 18: интерфейс провайдера услуг, простой веб-сервер, векторный API, фрагменты кода, повторная реализация рефлексии ядра, кодовая система UTF-8, второй инкубатор внешней функции и API памяти, второй предварительный просмотр сопоставления шаблонов для операторов switch, а также отказ от финализации, которая была последним дополнением.

Перед общей доступностью на 20 января 2022 года назначена вторая фаза rampdown. Кандидаты на выпуск должны быть представлены 10 февраля и 24 февраля следующего года.

В то время как JDK 17 был релизом с долгосрочной поддержкой (LTS), который будет поддерживаться Oracle не менее восьми лет, JDK 18 будет краткосрочным функциональным релизом, который будет поддерживаться в течение шести месяцев. Сборки JDK 18 с ранним доступом можно найти для Linux, Windows и MacOS на сайте java.net.

Конкретные спецификации предложений по JDK 18 включают:

• Избавьтесь от финализации, чтобы убрать ее в будущем выпуске. Finalizer имеет недостатки, которые вызывают значительные реальные проблемы в безопасности, производительности, надежности и ремонтопригодности. Кроме того, у него сложная модель программирования. Финализация пока включена по умолчанию, но может быть отключена для облегчения раннего тестирования. Она будет отключена по умолчанию в функциональном релизе и полностью удалена в более позднем релизе. Предложение предусматривает опцию командной строки для отключения финализации и обесценивание всех финализаторов и методов финализации в стандартном API Java. Цели предложения — помочь разработчикам понять опасность финализации, подготовить разработчиков к ее возможному удалению и предоставить простые инструменты для обнаружения зависимости от финализации. Введенная в Java 1.0, финализация была призвана помочь избежать утечки ресурсов. Класс может объявить финализатор — метод protected void finalize() — тело которого освобождает любой базовый ресурс. Сборщик мусора будет планировать вызов финализатора недоступного объекта до того, как он вернет память объекта; в свою очередь, метод finalize может выполнять такие действия, как вызов закрытия объекта. Это кажется эффективной системой безопасности для предотвращения утечек ресурсов, но существуют и недостатки, включая непредсказуемую задержку, когда между моментом, когда объект становится недоступным, и моментом вызова его финализатора проходит много времени; неограниченное поведение, когда код финализатора может выполнять любые действия, включая воскрешение объекта и повторное обращение к нему; финализатор всегда включен, без явного механизма регистрации; и финализаторы могут выполняться в неопределенных потоках в произвольном порядке. Учитывая проблемы с финализацией, разработчикам рекомендуется использовать альтернативные методы для предотвращения утечки ресурсов, а именно: операторы try-with-resources и очистители. (Подробности см. в предложении 421 по усовершенствованию JDK).
• Для SPI разрешения интернет-адресов предлагается определить SPI для разрешения адресов хостов и имен, чтобы Inet.Address мог использовать резолверы, отличные от встроенного в платформу резолвера. Мотивацией для этой работы является улучшение возможностей Project Loom для параллелизма и новых моделей программирования на Java, а также интеграция новых сетевых протоколов, настройка и возможность тестирования. Предложение не включает разработку альтернативного резолвера для JDK.
• Второй предварительный просмотр соответствия шаблонов для switch, в котором язык Java будет дополнен соответствием шаблонов для выражений и операторов switch, а также расширениями языка шаблонов. Это было представлено в JDK 17. Расширение сопоставления шаблонов для switch позволяет проверить выражение на соответствие нескольким шаблонам, каждый из которых имеет определенное действие, поэтому сложные запросы, ориентированные на данные, могут быть выражены кратко и безопасно.
• Воссоздание ядра отражения с помощью обработчиков методов позволит реализовать lang.reflect.Method, Constructor и Field поверх обработчиков методов java.lang.invoke. Использование обработчиков методов в качестве базового механизма для отражения позволит снизить затраты на обслуживание и разработку API java.lang.reflect и java.lang.invoke.
• В предложении простого веб-сервера предоставляется инструмент командной строки для запуска минимального веб-сервера, который обслуживает только статические файлы. Никакой CGI или сервлет-подобной функциональности не предусмотрено. Инструмент будет полезен для создания прототипов, специального кодирования и тестирования, особенно в образовательных контекстах. Цели плана включают предложение готового статического HTTP файлового сервера с простой настройкой и минимальной функциональностью, уменьшение энергии активации разработчика и повышение доступности JDK, а также предоставление реализации по умолчанию через командную строку вместе с небольшим API для программного создания и настройки. Предоставление многофункционального или коммерческого сервера не является целью данного предложения.
• Вторая инкубация API посторонних функций и памяти, в которой представлен API, с помощью которого Java-программы могут взаимодействовать с кодом и данными за пределами среды выполнения Java. Вызывая внешние функции — код вне JVM — и обеспечивая безопасный доступ к внешней памяти — памяти, не управляемой JVM — API позволяет Java-программам вызывать родные библиотеки и обрабатывать родные данные без хрупкости и опасности JNI (Java Native Interface). Цель состоит в том, чтобы заменить JNI превосходной, чистой моделью разработки Java. Этот API был разработан в JDK 17. В JDK 18 будут внесены уточнения, основанные на обратной связи, например, поддержка большего количества носителей, таких как Boolean и MemoryAddress в дескрипторах var доступа к памяти, и новый API для копирования массивов Java в сегменты памяти и из них.
• Векторный API будет представлен в JDK 18 в третий раз, до этого он был представлен в JDK 16 и JDK 17. Это предложение будет выражать векторные вычисления, которые компилируются во время выполнения в оптимальные векторные инструкции на поддерживаемых архитектурах CPU, достигая производительности, превосходящей эквивалентные скалярные вычисления. Векторные операции выражают степень распараллеливания, позволяя выполнять больше работы за один цикл процессора, что дает значительный прирост производительности. Векторный API, не зависящий от платформы, призван обеспечить возможность написания сложных алгоритмов на Java, используя существующий автовекторизатор HotSpot, но с пользовательской моделью, которая делает векторизацию более предсказуемой. JDK 18 также добавит поддержку платформы ARM Scalar Vector Extension и улучшит производительность векторных операций, принимающих маски, на архитектурах, поддерживающих маскирование аппаратно.
• Спецификация UTF-8 в качестве кодировки по умолчанию в стандартных API Java. UTF-8 — это широко распространенная кодировка символов для электронных коммуникаций, которая считается стандартной кодовой сеткой в Интернете. Charset — это кодировка символов, способная кодировать все символы в Интернете. Благодаря этому изменению, API, которые зависят от стандартной кодировки, будут вести себя последовательно во всех реализациях, операционных системах, локалях и конфигурациях. Предложение не направлено на определение новых API, соответствующих стандарту Java или JDK. Сторонники предложения ожидают, что приложения во многих средах не увидят никакого влияния от выбора Java в пользу UTF-8, поскольку MacOS, многие дистрибутивы Linux и многие серверные приложения уже поддерживают UTF-8. Однако в других средах существует риск, наиболее очевидный из которого заключается в том, что приложения, зависящие от кодовой таблицы по умолчанию, будут вести себя некорректно при обработке данных, полученных, когда кодовая таблица по умолчанию не была указана. Может произойти негласное повреждение данных. Ожидается, что основной удар придется на пользователей систем Windows в азиатских локалях и, возможно, на некоторые серверные среды в азиатских и других локалях.
• Сниппеты кода в документации Java API, предполагающий введение тега @snippet для стандартного доклета JavaDoc, чтобы упростить включение примеров исходного кода в документацию API. Среди целей плана — облегчение проверки фрагментов исходного кода путем предоставления API-доступа к этим фрагментам. Хотя за правильность отвечает автор, улучшенная поддержка в JavaDoc и соответствующих инструментах может облегчить ее достижение. Среди других целей — обеспечение современной стилизации, такой как подсветка синтаксиса, а также автоматическая привязка имен к декларациям, и улучшение поддержки IDE для создания и редактирования фрагментов. В предложении отмечается, что авторы документации API часто включают фрагменты исходного кода в комментарии к документации.