Статьи

Возможности Java / Java EE SKP: Java SE 9 Особенности: Что нового?

Ниже я представил некоторые наиболее важные усовершенствования языка ядра для JDK 9.0. Цель этой статьи — познакомить вас с новыми функциями Java SE 9. Это включает в себя главным образом концептуальное представление функций. Это почти завершенные функции, которые были приняты и официально объявлены Oracle. Выпуск Java 9 запланирован на конец июля 2017 года.

КРАТКОЕ НАЗВАНИЕ ХАРАКТЕРИСТИКИ

Подзаголовок / область

JEP 261: модульная система

Модульная система в JDK 9

JEP 200: модульный JDK

Модульная система в JDK 9

JEP 220: модульные изображения во время выполнения

Модульная система в JDK 9

JEP 260: инкапсулировать большинство внутренних API

Модульная система в JDK 9

JEP 223: новая версия-строковая схема

Изменения в JDK 9

Включить или отключить веб-развертывание с помощью интерфейса установщика

Установщик JDK 9

JEP 158: унифицированное ведение журнала JVM

Инструменты в JDK 9

JEP 214: удалить комбинации GC, устаревшие в JDK 8

Инструменты в JDK 9

JEP 222: jshell: оболочка Java (цикл чтения-проверки-печати)

Инструменты в JDK 9

JEP 224: HTML5 Javadoc

Инструменты в JDK 9

JEP 228: добавить больше диагностических команд

Инструменты в JDK 9

JEP 231: удалить выбор версии JRE времени запуска

Инструменты в JDK 9

JEP 240: удаление агента JVM TI hprof

Инструменты в JDK 9

JEP 241: удалить инструмент jhat

Инструменты в JDK 9

JEP 245: проверка аргументов флага командной строки JVM

Инструменты в JDK 9

JEP 247: компиляция для более старых версий платформы

Инструменты в JDK 9

JEP 282: jlink: компоновщик Java

Инструменты в JDK 9

JEP 219: безопасность транспортного уровня дейтаграмм (DTLS)

Безопасность в JDK 9

JEP 244: расширение согласования протокола прикладного уровня TLS

Безопасность в JDK 9

JEP 249: сшивание OCSP для TLS

Безопасность в JDK 9

JEP 246: использование инструкций процессора для GHASH и RSA

Безопасность в JDK 9

JEP 273: реализации SecureRandom на основе DRBG

Безопасность в JDK 9

JEP 229. Создание PKCS12 Keystores по умолчанию

Безопасность в JDK 9

JEP 287: алгоритмы хеширования SHA-3

Безопасность в JDK 9

Устаревать плагин Java

Развертывание в JDK 9

Улучшенная панель управления Java

Развертывание в JDK 9

JEP 275: модульная упаковка приложений Java

Развертывание в JDK 9

JEP 289: устареть API апплета

Развертывание в JDK 9

JEP 213: фрезерная монета проекта

Язык Java в JDK 9

JEP 221: упрощенный Doclet API

Javadoc в JDK 9

JEP 224: HTML5 Javadoc

Javadoc в JDK 9

JEP 225: поиск Javadoc

Javadoc в JDK 9

JEP 261: модульная система

Javadoc в JDK 9

JEP 165: управление компилятором

ВМ в JDK 9

JEP 197: кеш сегментированного кода

ВМ в JDK 9

JEP 276: динамическое связывание языковых моделей объектов

ВМ в JDK 9

JEP 271: унифицированная регистрация GC

JVM Тюнинг в JDK 9

JEP 248: сделать G1 сборщиком мусора по умолчанию

JVM Тюнинг в JDK 9

JEP 102: обрабатывать обновления API

Основные библиотеки в JDK 9

JEP 193: переменные ручки

Основные библиотеки в JDK 9

JEP 254: компактные струны

Основные библиотеки в JDK 9

JEP 264: API ведения журнала платформы и сервис

Основные библиотеки в JDK 9

JEP 266: больше обновлений параллелизма

Основные библиотеки в JDK 9

JEP 268: каталоги XML

Основные библиотеки в JDK 9

JEP 269: методы фабрики удобства для коллекций

Основные библиотеки в JDK 9

JEP 274: улучшенные дескрипторы методов

Основные библиотеки в JDK 9

JEP 277: улучшенная амортизация

Основные библиотеки в JDK 9

JEP 285: подсказки с вращением

Основные библиотеки в JDK 9

JEP 290: фильтр входящих данных сериализации

Основные библиотеки в JDK 9

JEP 259: API стека

Основные библиотеки в JDK 9

JEP 236: парсер API для Nashorn

Нашорн в 9 JDK

JEP 292: внедрить выбранные функции ECMAScript 6 в Nashorn

Нашорн в 9 JDK

JEP 251: изображения с высоким разрешением

Клиентские технологии в JDK 9

JEP 256: Аннотации BeanInfo

Клиентские технологии в JDK 9

JEP 262: TIFF Image I / O

Клиентские технологии в JDK 9

JEP 263: графика HiDPI в Windows и Linux

Клиентские технологии в JDK 9

JEP 272: специфичные для платформы функции рабочего стола

Клиентские технологии в JDK 9

JEP 283: включить GTK 3 в Linux

Клиентские технологии в JDK 9

JEP 267: Unicode 8.0

Интернационализация в JDK 9

JEP 252: данные локали CLDR включены по умолчанию

Интернационализация в JDK 9

JEP 226: файлы свойств UTF-8

Интернационализация в JDK 9

Список изменений в JDK 9

Как разработчик, те, которые влияют на нашу повседневную жизнь, в основном относятся к следующим областям:

  1. Язык Java в JDK 9

  2. Основные библиотеки в JDK 9

Официальный релиз Oracle : июль 2017

Хотя другие также очень важны, они могут быть изучены, исследованы и освоены, если и когда возникнет такая необходимость. Прежде чем мы перейдем к изменениям в Java 9, давайте коснемся одного аспекта Java 8, о котором нам нужно знать больше.


Методы интерфейса по умолчанию

Всякий раз, когда существует существующий или унаследованный код, который имеет интерфейсы , требующие добавления новых методов, он вызывает разрыв существующих классов, которые наследуют / реализуют из этого интерфейса,  если в классах не предусмотрена реализация для каждого из этих добавленных методов. Это не делает для очень поддерживаемого кода. Несмотря на то, что согласно SOLID и другим  парадигмам OO , хорошей практикой является предоставление интерфейса без какой-либо реализации, нам необходимо решить и решить проблему, как указано выше. Это где методы интерфейса по умолчанию входят.

import java.util.List;  

public interface LegacyPublicInterface {  

    /**  
    * Additional Default Method that Can be Invoked on Each Type of Invoice that Implements the LegacyPublicInterface.   
    * It can also be over-ridden by the Extending Invoice Types. This is an Example Usage and Benefit of the Java/JDK 8  
    * Default Interface feature.  
    * @param items  
    */  
    default void checkStatusOnEachItem (List<String>... items) {  

        for(String item : items) {  
            if(item.startsWith("OOS_")) {  
                items.remove(item);  
            }  
        }  
        return;  
    }  

}  

Из приведенного выше примера  LegacyPublicInterface  в  существующем приложении  уже расширен несколькими типами счетов (например, в системе инвентаризации). Но в соответствии с изменяющимися бизнес-требованиями, процесс реинжиниринга требует, чтобы в каждом из счетов был метод для аннулирования или удаления элемента, помеченного «OOS». Учитывая такую ​​проблему, до Java 8 нам пришлось бы ввести новое объявление метода в интерфейс, а затем потребовать, чтобы каждый из реализующих классов реализовал свою собственную логику для обработки этого.

С интерфейсами по умолчанию задача становится очень простой (код теперь более понятен и расширяем и требует гораздо меньше усилий для изменения). С введением этой функции методов по  умолчанию , следующие возможности:

  1. Используйте метод (ы) по умолчанию, не нарушая существующую функциональность (наилучшее использование).

  2. Реализующий класс может переопределить эти методы по умолчанию.

  3. Абстрактные интерфейсы могут быть предоставлены через интерфейсы для переопределения реализации.

Итак, давайте подробнее рассмотрим каждое из этих изменений в Java 9.

Язык Java в JDK 9

JEP 213: фрезерная монета проекта

@SafeVarargs разрешено в методах частной инстанции

Использование в методе параметров аргументов без переопределения может вызвать несколько предупреждений при попытке компилировать код, например:

Note: LegacyPublicInterface.java uses unchecked or unsafe operations.  
Note: Recompile with -Xlint:unchecked for details.

Следовательно, @SafeVarargs были введены для подавления таких предупреждений о непроверенных или небезопасных операциях. Используя это, разработчики сообщают компилятору, что они позаботились о том, чтобы не было никакого загрязнения кучи (например, небезопасных операций forEach ).

До Java 9 @SafeVarargs было разрешено для не переопределяемых методов, таких как статические методы, методы конечных экземпляров и конструкторы. Обратите внимание, что аннотация выдаст ошибку, если она используется в методах фиксированной арности.

В Java 9 @SafeVarargs можно использовать в методах частного экземпляра.

Подчеркивать как имя переменной больше не разрешено

Использование только _ (символ подчеркивания) в качестве имени переменной больше недопустимо. Это потому, что оно помечено как зарезервированное ключевое слово в Java 1.8 (но вызывает сбой компиляции только в Java 1.9).

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

Методы частного интерфейса были введены

Интерфейсы в Java 9 могут иметь частные методы. Это было сделано для обеспечения совместного использования кода между неабстрактными методами в Интерфейсе. Все правила, относящиеся к обычному модификатору Private, применяются к этим методам. Следует отметить, что метод не может быть как частным, так и абстрактным. Это определенно должно иметь тело метода.

Разрешить эффективно использовать конечные переменные в качестве ресурсов в Try-With-Resources

До Java 8 каждая переменная, которая должна была использоваться в инструкциях Try-with-Resources, должна быть объявлена ​​в инструкции try. Только тогда он может быть использован в блоке try. Это ограничение для разработчика. Следовательно, в Java 9 это ограничение было снято, и любая конечная переменная или эффективно конечная (локальная) переменная может использоваться внутри блока try. Все остальные правила, применимые к Try-with-Resources, продолжаются. Окончательно означает, что переменная не изменяется ни разу после ее инициализации.

Разрешить алмаз с анонимными классами, если тип аргумента предполагаемого типа является помечаемым

До Java 8 с использованием обобщенных и алмазных операторов с анонимными классами. Это было главным образом потому, что компилятор не мог определить, может ли он представлять тип в аргументе, передаваемом оператору Diamond. JSR 334 может сказать следующее об использовании diamond с анонимными классами:


«Использование diamond с анонимными внутренними классами не поддерживается, поскольку для этого обычно требуется расширение атрибута подписи файла класса для представления недетонируемых типов, фактическое
изменение JVM ».

Дополнительная информация находится в теме Diamond Operator and Anonymous Classes в списке рассылки Project Coin :


«Внутренне, компилятор Java работает с более богатым набором типов, чем те, которые могут быть записаны явно в программе Java. Внутренние типы компилятора, которые не могут быть записаны в программе Java, называются
недетонируемыми типами. Это может произойти в результате логического вывода, используемого diamond. Поэтому использование diamond с анонимными внутренними классами не поддерживается, поскольку в целом для этого требуются расширения атрибута подписи файла класса для представления недетонируемых типов, что является фактическим изменением JVM. Вполне возможно, что будущие версии платформ позволят использовать diamond при создании анонимного внутреннего класса, если выводимый тип может быть денотируемым ».

В Java 9 компилятор Java изменил свой алгоритм вывода таким образом, что теперь Diamond Operator (Generics) может работать одновременно с анонимными классами, если тип аргумента типа Inferred является Denotable . Важным моментом, который следует отметить, является то, что под Denotable входят типы Primitive, Raw-типы и неуниверсальные типы . Не денотируемые означают те, которые не могут быть написаны в Java-программе, например, использование Extends и Super вместе с типами подстановочных знаков в Generics. Обычно они определяются компилятором. Таким образом, пока компилятор определяет, что тип аргумента типа Inferred является Denotable, вы можете использовать оператор Diamond в сочетании с анонимными внутренними классами.

Основные библиотеки в JDK 9

JEP 102: обрабатывать обновления API

С Java 9 можно получить PID процесса через собственный вызов. Это достижимо через ProcessHandle . Кроме того, мы можем получить информацию о текущем запущенном Java-процессе (JVM) и Info (внутренний класс ProcessHandle) Class / Object, который содержит подробную информацию о процессе. Мы также можем подключить или вернуть снимок всех запущенных в данный момент процессов в системе.

JEP 193: переменные ручки

Параллельный пакет Java (java.util.concurrent.atomic) предоставляет все атомарные типы для выполнения атомарных операций. Помимо этого, небезопасные операции (sun.misc.unsafe), такие как создание объектов без вызова конструктора, используемого в низкоуровневом программировании Java, должны быть скрыты от внешнего мира в соответствии с JEP 260: инкапсуляция большинства внутренних API-интерфейсов . Это привело к созданию нового абстрактного типа класса с именем VarHandle, Это позволит разработчику назначать разные типы для одной и той же ссылки (динамически типизированные ссылки). Он также может позаботиться о выполнении атомарных операций с хранимой переменной, включая операции сравнения и замены (установки или обмена). Он также обеспечивает операции ограждения памяти, чтобы упорядочить представление объекта в памяти, обеспечивая более точное управление зернистостью.

JEP 254: компактные струны

Хотя это не имеет внешних последствий для разработчика с точки зрения изменения синтаксиса или семантики, это может повлиять на то, как мы проектируем память и производительность. Текущее представление UTF-16 использует 2 байта для хранения . Большая часть строки содержит символы, которые имеют только латиницу-1 по своей природе. Для символов Latin-1 требуется только 1 байт для хранения . В Java 9 хранилище строк было изменено для запуска с дополнительным флагом кодирования . Этот флаг указывает, содержит ли он символы ISO-8859-1 / Latin-1 или символы UTF-16. Согласно официальному слову, это привело к улучшенному использованию памяти и эффективному сборщику мусора, но с некоторой потерей производительности при пиковых нагрузках.

JEP 264: API ведения журнала платформы и сервис

Это определяет  минимальный API ведения журнала для платформы, а также предоставляет сервисный интерфейс для потребителей этих сообщений. Реализация этого интерфейса может быть обеспечена путем регистрации библиотек или самого приложения, чтобы соответствующим образом направить сообщения в используемую среду регистрации приложений или используемую реализацию, такую ​​как [Log4J или SLF4J]. Всякий раз, когда реализация недоступна, среда выполнения переключается на пакет ведения журнала Java по умолчанию. (java.logging). Это также позволяет нам обнаруживать проблемы Bootstrap.

JEP 266: больше обновлений параллелизма

На параллельности постоянно развивается мыслительный процесс . В Java 9 была предоставлена совместимая среда публикации и подписки . Кроме того, были предоставлены усовершенствования объекта CompletableFuture , а также многочисленные улучшения реализации по сравнению с JDK 8, включая переписывание Javadoc. Взаимодействующая среда публикации-подписки, также известная как реактивные потоки ,  обеспечивает двустороннюю связь на основе трафика или объема на каждом конце потока, издателя и подписчика. Усовершенствования API CompletableFuture включают методы, которые позволяют Future завершаться со значением или с исключением после периода ожидания . ТакжеЗадержанный исполнитель был предоставлен, чтобы разрешить выполнение задачи после некоторой задержки.

JEP 268: каталоги XML

Каталог XML состоит из записей одной или нескольких из Каталога файлов входа. Каталог файлов запись является XML — файл , чей документ элемент каталога и содержание которого следует Каталог XML DTD , определенный OASIS. В Java 9 существует открытый API для управления каталогом XML. Внешние ссылки в каталоге необходимо разрешать многократно. Но с этим новым API, API, содержащий CatalogManager, Catalog и CatalogResolverможет использоваться для уменьшения или устранения этих внешних вызовов, когда ресурс каталога уже существует локально. Он создает локальный каталог и позволяет процессорам на основе JAXP преобразовываться в этот локальный каталог.

JEP 269: методы фабрики удобства для коллекций

Это дополнение позволяет разработчикам создавать неизменяемые коллекции из существующих коллекций, будь то набор, карта или список. Статический метод фабрики () добавлен к каждому из интерфейсов — Set, Map и List. Важно понимать следующее (даже если это согласуется с предыдущими версиями Java):

  • Они структурно неизменны .
  • Они запрещают нулевые элементы или нулевые ключи.
  • Они сериализуемы, если все элементы сериализуемы.
  • Они отклоняют дубликаты элементов / ключей во время создания.
  • Порядок итерации заданных элементов не указан и может быть изменен .
  • Они основаны на стоимости . Фабрики могут создавать новые экземпляры или повторно использовать существующие. Поэтому чувствительные к идентификации операции в этих случаях (ссылочное равенство ( == ), хэш-код идентификации и синхронизация ) ненадежны и их следует избегать. Они сериализуются, как указано на странице «Сериализованная форма».

JEP 274: улучшенные дескрипторы методов

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

JEP 277: улучшенная амортизация

Принимая во внимание обслуживаемый и более информативный код,  определяемый разработчиком устаревший контент теперь позволяет помечать устаревший с помощью дополнительных элементов информации, таких как forRemoval и с тех пор. ForRemoval позволяет отметить , что этот элемент может быть удален в будущих версиях Java, и так как содержит информацию о том, когда он впервые был введен.

JEP 285: подсказки с вращением

Для многопоточных приложений это приводит к некоторым улучшениям производительности в условиях ожидания занятости или ожидания вращения . Обычно Ожидание занято выполняется для синхронизации некоторого состояния объекта между двумя или более инициаторами — Ожидание возникновения условия до начала или продолжения обработки. Thread.onSpinWait () был представлен как статический метод в классе Thread и может вызываться при необходимости в циклах Busy-Waiting.

Это позволит JVM выдавать инструкции процессора на некоторых архитектурах системы, чтобы сократить время реакции в таких циклах Spin-Wait, а также уменьшить мощность, потребляемую основным потоком или аппаратным потоком . Это способствует общему энергопотреблению программы  и, возможно, позволяет другим ядрам или аппаратным потокам выполняться с более высокими скоростями в пределах той же огибающей.

JEP 290: фильтр входящих данных сериализации

Эта функция связана с добавлением фильтров при сериализации входящих потоков для повышения безопасности и надежности. Основным механизмом является интерфейс фильтра, реализованный клиентами сериализации и установленный в ObjectInputStream . Методы интерфейса фильтра вызываются во время процесса десериализации для проверки десериализованных классов, размеров создаваемых массивов и метрик, описывающих длину потока, глубину потока и количество ссылок при декодировании потока. Фильтр возвращает статус, чтобы принять, отклонить или оставить статус неопределенным.

JEP 259: API стека

До Java 9 способ доступа к Stack Trace был очень ограниченным и предоставлял всю информацию о дампе или стеке одновременно. Это было неэффективно и не позволяло никакой прямой фильтрации данных. С Java 9, A Ленивый StackWalker API был введен . Это позволит нам получать данные на основе условий фильтрации и является более эффективным.

Впереди на полной скорости, с Java 9! 

Готовая ссылка на DZone

Возможно, вы заметили, что в отличие от других моих статей, я не предоставил примеры кода для каждой из новых функций. Статьи, на которые я ссылаюсь здесь, включают мою серию статей по истории выпусков Java SE, начиная с Java SE 5. Я расширю эту текущую статью, которую вы читаете, подробными примерами кода (так как это новые функции) через некоторое время , Я опубликую то же самое в серии статей «SKP Java / Java EE Gotchas». До тех пор я прошу вас прочитать вышеупомянутую статью еще раз и позволить всем концепциям обосноваться. 

Проверьте мою   страницу GitHub для полного кода и многое другое.