[Java] JDK 17: новые функции в Java 17 (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
01-Июн-2021 02:30

Цитировать

Всегда строгая семантика с плавающей запятой
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 появляются каждые шесть месяцев.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Paul Krill
===========Похожие новости:

Теги для поиска: #_java, #_java_17, #_java, #_razrabotka_po (разработка по), #_jazyki_prorammirovanija (языки прораммирования), #_java

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 13:13
Часовой пояс: UTC + 5