JDK 17: новые функции в Java 17
Всегда строгая семантика с плавающей запятой
API сторонних функций и памяти
Унифицированный API для генераторов псевдослучайных чисел
Версия Java 17, которая должна выйти в сентябре, продолжает набирать форму, на данный момент запланировано девять функций для обновления до стандартной Java, а также удаление двух функций и две функции прекращают поддерживаться. В последних изменениях, на 24 мая, было добавлено сопоставление с образцом для switch выражений и восстановлена всегда строгая семантика с плавающей запятой.
Java Development Kit (JDK) 17 будет релизом с долгосрочной поддержкой (LTS), с расширенной поддержкой Oracle, ожидаемой в течение нескольких лет. Функции, представленные как часть OpenJDK’s JDK 17, включают следующее:
С восстановлением всегда строгой семантики с плавающей запятой, операции с плавающей запятой будут постоянно строгими, вместо того, чтобы иметь как строгую семантику с плавающей запятой (strictfp), так и слегка отличающуюся семантику с плавающей запятой по умолчанию. Это восстанавливает исходную семантику с плавающей запятой для языка и виртуальной машины, соответствуя семантике до введения строгих режимов и режимов с плавающей запятой по умолчанию в Java Standard Edition 1.2. Цели этих затрат включают облегчение разработки библиотек, чувствительных к числовым значениям, включая java.lang.Math и java.lang.StrictMath. Стимул к изменению семантики с плавающей запятой по умолчанию в конце 1990-х гг. был вызван плохим взаимодействием между исходным языком Java и семантикой JVM, а также некоторыми особенностями набора команд сопроцессора с плавающей запятой x87 популярной архитектуры x86. Соответствие точной семантике с плавающей запятой во всех случаях, включая субнормальные операнды и результаты, требовало больших накладных расходов дополнительных инструкций. Сопоставление результатов при отсутствии переполнения или потери значимости может быть выполнено с меньшими накладными расходами, и это примерно то, что позволяет пересмотренная семантика с плавающей запятой по умолчанию, представленная в Java SE 1.2. Но расширения SSE2 (Streaming SIMD Extensions 2), поставляемые в процессорах Pentium 4 и более поздних версиях, начиная примерно с 2001 г., могли напрямую поддерживать строгие операции с плавающей запятой JVM без чрезмерных накладных расходов. Поскольку Intel и AMD поддерживают SSE2 и более поздние расширения, которые позволяют естественную поддержку строгой семантики с плавающей запятой, технической мотивации для использования семантики с плавающей запятой по умолчанию, отличной от строгой, больше не существует.
Прекращение поддержки Security Manager, подготовка к удалению в следующем выпуске. Начиная с Java 1.0, Security Manager был основным средством защиты кода Java на стороне клиента и редко использовался для защиты кода на стороне сервера. Цель предложения — оценить, нужны ли новые API или механизмы для решения конкретных узких вариантов использования, для которых использовался Security Manager, например, для блокировки System: exit. Планы предусматривают прекращение поддержки Security Manager для удаления вместе с устаревшим Applet API, который также планируется исключить в JDK 17.
Сопоставление с образцом для switch расширяет язык шаблонов в Java, позволяя тестировать выражения и операторы switch по ряду шаблонов, каждый из которых имеет определенное действие. Это позволяет кратко и безопасно выражать сложные запросы, ориентированные на данные. В число целей этой функции входит расширение выразительности и применения выражений и операторов switch путем включения шаблонов в метки case, ослабление исторической враждебности к нулю при необходимости switch и введение двух типов шаблонов: защищенных шаблонов, которые позволяют уточнять логику сопоставления должна быть уточнена с помощью произвольных логических выражений и шаблонов в скобках, которые разрешают некоторые неоднозначности синтаксического анализа. В JDK 16 оператор instanceof был расширен, чтобы принимать образец типа и выполнять сопоставление с образцом. Предлагаемое скромное расширение позволяет упростить знакомую идиому instanceof-and-cast.
Строгая инкапсуляция для внутренних компонентов JDK, за исключением критически важных внутренних API, таких как misc.unsafe, сделает невозможным ослабление строгой инкапсуляции внутренних элементов с помощью единственной опции командной строки, как это было возможно в JDK 9 — JDK 16. Цели плана включают повышение безопасности и удобства сопровождения JDK, а также поощрение разработчиков к переходу от внутренних элементов к стандартным API.
Удаление механизма активации удаленного вызова метода (RMI) с сохранением остальной части RMI. Механизм активации RMI устарел, не используется и был объявлен устаревшим для удаления в JDK 15.
Внешняя функция и API памяти, представленные на стадии зарождения, позволяют программам Java взаимодействовать с кодом и данными вне среды выполнения Java. За счет эффективного вызова внешних функций, т.е. кода вне JVM, и безопасного доступа к внешней памяти, т.е. памяти, не управляемой JVM, API позволяет программам Java вызывать собственные библиотеки и обрабатывать собственные данные без хрупкости и риска JNI (Java Native Interface). Предлагаемый API представляет собой эволюцию двух API — API доступа к внешней памяти и API внешнего компоновщика. API доступа к внешней памяти был нацелен на Java 14 в 2019 году как инкубирующий API и возрожден в Java 15 и Java 16. API внешнего компоновщика был нацелен на Java 16 как зарождающийся API в конце 2020 года. Цели плана API включают простоту использования, производительность, универсальность и безопасность.
Внедренный в JDK 16 в качестве зарождающегося API, независимый от платформы vector API будет снова возрожден в JDK 17, обеспечивая механизм для выражения векторных вычислений, которые надежно компилируются во время выполнения в оптимальные векторные инструкции на поддерживаемых архитектурах ЦП. Это обеспечивает лучшую производительность, чем эквивалентные скалярные вычисления. В JDK 17 vector API был улучшен для повышения производительности и реализации, включая улучшения для преобразования байтовых векторов в логические массивы и наоборот.
Закрытые классы и интерфейсы ограничивают то, что другие классы или интерфейсы могут расширять или реализовывать. Цели предложения включают в себя разрешение автору класса или интерфейса контролировать, какой код отвечает за его реализацию, предоставление более декларативного способа, чем модификаторы доступа для ограничения использования суперкласса, и поддержка будущих направлений сопоставления с образцом, обеспечивая основу для исчерпывающего анализа паттернов.
Удаление экспериментального компилятора AOT и JIT, который мало использовался, но требует значительных усилий по обслуживанию. План призывает поддерживать интерфейс компилятора JVM на уровне Java, чтобы разработчики могли продолжать использовать созданные извне версии компилятора для JIT-компиляции. Компиляция AOT (инструмент jaotc) была включена в JDK 9 в качестве экспериментальной функции. Инструмент использует компилятор Graal, который сам написан на Java, для компиляции AOT. Эти экспериментальные функции не были включены в сборки JDK 16, опубликованные Oracle, и никто не жаловался. Согласно предписанному плану, три модуля JDK будут удалены: jdk.aot (инструмент jaotc); internal.vm.compiler, компилятор Graal; и jdk.internal.vm.compiler.management, MBean Graal. Также будет удален код HotSpot, связанный с компиляцией AOT.
Перенос JDK на MacOS / AArch64 в ответ на план Apple по переходу своих компьютеров Macintosh с x64 на AArch64. Порт AArch64 для Java уже существует для Linux, и в настоящее время ведутся работы для Windows. Разработчики Java рассчитывают повторно использовать существующий код AArch64 из этих портов, применяя условную компиляцию, как это обычно бывает в портах JDK, чтобы учесть различия в низкоуровневых соглашениях, таких как двоичный интерфейс приложения и набор зарезервированных регистров процессора. Изменения для MacOS / AArch64 могут привести к поломке существующих портов Linux / AArch64, Windows / AArch64 и MacOS / x64, но риск будет снижен за счет тестирования перед интеграцией.
Устарело использование Applet API для удаления. Этот API по сути не имеет значения, поскольку все поставщики веб-браузеров либо удалили поддержку подключаемых модулей браузера Java, либо объявили о планах сделать это. Applet API ранее был объявлен устаревшим, но не подлежал удалению в Java 9 в сентябре 2017 года.
Новый конвейер рендеринга для MacOS, использующий Apple Metal API в качестве альтернативы существующему конвейеру, который использует устаревший API OpenGL. Это предложение предназначено для обеспечения полнофункционального конвейера рендеринга для Java 2D API, который использует структуру MacOS Metal, и быть готовым на случай, если Apple удалит OpenGL API из будущей версии MacOS. Предполагается, что конвейер будет иметь функциональный паритет с существующим конвейером OpenGL, с производительностью, такой же или более высокой в отдельных приложениях и тестах. Будет создана чистая архитектура, которая вписывается в текущую 2D-модель Java. Этот конвейер будет сосуществовать с конвейером OpenGL до тех пор, пока он не станет устаревшим. Целью предложения не является добавление каких-либо новых API-интерфейсов Java или JDK.
Усовершенствованные генераторы псевдослучайных чисел, которые будут предоставлять новые типы интерфейсов и реализации для генераторов псевдослучайных чисел (PRNG), включая изменяемые PRNG и дополнительный класс алгоритмов разделяемого PRNG (LXM). Новый интерфейс RandomGenerator предоставит единый API для всех существующих и новых PRNG. Будет предоставлено четыре специализированных интерфейса RandomGenerator. Мотивация плана — сосредоточение внимания на нескольких областях для улучшения в области генерации псевдослучайных чисел в Java. Эти усилия не требуют реализации множества других алгоритмов PRNG. Но были добавлены три общих алгоритма, которые уже широко используются в других средах языков программирования. Цели плана включают:
Упрощение взаимозаменяемого использования различных алгоритмов PRNG в приложениях.
Улучшена поддержка потокового программирования, предоставляющего потоки объектов PRNG.
Устранение дублирования кода в существующих классах PRNG.
Сохранение существующего поведения класса java.util.Random.
14 сентября намечено сделать JDK 17 общедоступной. Производственному выпуску будут предшествовать этапы свертывания в июне и июле, а выпуск кандидатов — в августе. Сборки JDK 17 с открытым исходным кодом для раннего доступа можно найти на jdk.java.net.
Релизы LTS, такие как JDK 17, появляются каждые три года. Последний релиз LTS, JDK 11, был опубликован в сентябре 2018 года. Новые версии Java появляются каждые шесть месяцев.
