JDK 15: новые функции
Свежее обновление стандартных возможностей: текстовых блоков (прим.пер. Text Blocks), скрытых классов (прим.пер. Hidden Classes), сборщика мусора Z и предварительных версий сопоставлений с образцом (прим.пер. Pattern Matching) и записей (прим.пер. Records)
Paul Krill, ведущий редактор Infoworld
Java Development Kit 15, следующая версия Java SE (Standard Edition) в реализации Oracle, станет доступна в качестве официального релиза сегодня, 15 сентября 2020 года. Основные новшества JDK 15 вносит в текстовые блоки, скрытые классы, API доступа к внешней памяти, сборщик мусора Z , а также в ознакомительные возможности: запечатанные классы (прим.пер. Sealed Classes), сопоставление с образцом и записи.
JDK 15 — это только краткосрочный релиз, который будет поддерживаться Oracle Premier Support в течение шести месяцев, пока в марте следующего года не выйдет JDK 16. Через год, согласно шестимесячной каденции выпуска Oracle для версий Java SE, должен выйти следующий долгосрочный релиз JDK 17, который будет поддерживаться Oracle в течение восьми лет.
Джордж Сааб, президент Java Platform Group Oracle сказал, что разработчики сейчас могут ознакомиться с JDK 15 и получить представление о новинках JDK 17. Текущей версией LTS (прим.пер. Long Time Support — долгосрочная поддержка) является JDK 11, выпущенный в сентябре 2018 года. Релизы LTS выпускаются раз в три года. JDK 15 следует за JDK 14, выпущенным 17 марта 2020 года.
Новые возможности и изменения в OpenJDK 15:
• Вторая фаза инкубации API доступа к внешней памяти, с помощью которого программы Java могут безопасно и эффективно получать доступ к областям внешней памяти вне динамически распределяемой кучи (heap) Java. API должен работать с различными видами внешней памяти, нативной, постоянной и управляемой кучами. Многие программы Java обращаются к внешней памяти, например Ignite и MapDB. API поможет избежать расхода ресурсов и непредсказуемости, вызванных сбором мусора, распределять память между процессами, а также сериализовать и десериализовать содержимое памяти путем сопоставления файлов с памятью. Java API до сих пор не предоставляет удовлетворительного решения по доступу к внешней памяти. Но новые изменения не дадут возможность API нарушать безопасность виртуальной машины Java. Эта возможность прошла раннюю фазу инкубации в JDK 14, и её новые усовершенствования предложены в JDK 15.
• Предварительный просмотр запечатанных классов. Запечатанные классы и интерфейсы определяют, какие другие классы и интерфейсы могут расширять или реализовывать их. Эта функция позволяет автору класса или интерфейса контролировать, какой код отвечает за его реализацию, предоставлять более явный, чем модификаторы доступа, способ для ограничения использования суперкласса, и поддерживать будущие возможности сопоставления с образцом через исчерпывающий анализ образцов.
• Удаление исходного кода и поддержки сборок для платформ Solaris/SPARC, Solaris/x64 и Linux/SPARC, объявленных в JDK 14 устаревшими и подлежащими удалению в будущем выпуске. Многие разрабатываемые проекты и функции, такие как Valhalla, Loom и Panama, требуют значительных изменений в архитектуре процессора и специфичном для операционной системы коде. Отказ от поддержки платформ Solaris и SPARC позволит участникам сообщества OpenJDK ускорить разработку новых функций и развитие платформы. Solaris, и SPARC были вытеснены в последние годы ОС Linux и процессорами Intel.
• Записи, являющиеся классами, выступающие в качестве транспарентных носителей неизменяемых данных, будут включены в JDK 15 в состоянии второго предварительного ознакомления, поскольку впервые они появились в JDK 14 для раннего предварительного ознакомления. Целью является разработка объектно-ориентированной концепции, которая выражается в простом агрегировании значений, что поможет программистам сосредоточиться на моделировании неизменяемых данных, а не на расходящихся вариантах поведения, на автоматической реализации данных методов, и соответствует давним принципам Java, а именно строгой типизации и обратной совместимости. Записи можно рассматривать как набор данных.
• Криптографические подписи, основанные на алгоритме цифровой подписи Edwards-Curve (EdDSA). EdDSA-это современный алгоритм эллиптической кривой, обладающий преимуществами перед существующими алгоритмами сигнатур в JDK. EdDSA будет реализован только в провайдере SunEC. EdDSA пользуется спросом из-за улучшений безопасности и производительности по сравнению с другими алгоритмами подписи; и уже поддерживается в криптографических библиотеках OpenSSL и BoringSSL.
• Переопределение устаревшего API DatagramSocket заменой базовых реализаций java.net.datagram.API Socket и java.net.MulticastSocket более простыми и современными реализациями, которые 1) просты в отладке и обслуживании, и 2) работают с виртуальными потоками, которые в настоящее время изучаются в Project Loom. Новый план является развитием предложения 353 по улучшению JDK, переопределившим устаревший API сокетов. Текущие реализации java.net.datagram.Socket и java.net.MulticastSocket тянутся ещё из JDK 1.0, из того времени, когда IPv6 еще находился в стадии разработки. Таким образом, текущая реализация MulticastSocket пытается согласовать IPv4 и IPv6 способами, которые трудно продолжать поддерживать.
• Отключение biased locking по умолчанию и отмена всех связанных с ней параметров командной строки. Целью является определить необходимость затратной поддержки устаревшей оптимизации синхронизации biased locking в виртуальной машине HotSpot, используемой для снижения расхода ресурсов на незапланированную блокировку. Хотя у некоторых Java-приложений падает производительность при отключенной biased locking, выигрыш в производительности от biased locking стал менее заметным, чем раньше.
• Второе превью Pattern-matching для instanceof, после первого в JDK 14. Сопоставления с образцом позволяют легче и лаконичней выразить общую логику программы, главным образом через удобный доступ к объекту установленного типа. Такие языки, как Haskell и C#, используют сопоставление с образцом из-за его краткости и безопасности.
• Скрытые классы, то есть классы, которые не могут быть использованы непосредственно байт-кодом других классов, предназначены для использования фреймворками, генерирующими классы во время выполнения и использующими их косвенно через рефлексию. Скрытый класс может быть определен как элемент Nest-Based Access Control и выгружен независимо от других классов. Эта возможность повысит эффективность всех языков в JVM, позволив стандартному API определять скрытые классы, которые не обнаруживаются и имеют ограниченный жизненный цикл. Фреймворки внутри и вне JDK могут динамически генерировать классы, вместо определения скрытых классов. Многие языки, построенные на JVM полагаются на динамическую генерацию классов для обеспечения гибкости и эффективности. Цели этого нововведения включают в себя разрешение фреймворкам определять классы как скрытые детали реализации фреймворка, чтобы они не были связаны с другими классами или обнаружены с помощью рефлексии; поддержку расширения Nest-Based Access Control с помощью не обнаруживаемых классов; а также поддержку агрессивной выгрузки скрытых классов, что позволит фреймворкам использовать практически любое количество таких классов. Другая цель состоит в том, чтобы отказаться от нестандартного API, misc.Unsafe::defineAnonymousClass, с намерением удалить их в будущем выпуске. Кроме того, язык Java не должен меняться в результате появления этой возможности.
• Сборщик мусора Z (ZGC) переходит от экспериментальной функции к статусу продукта в данной версии. Появившийся в сентябре 2018 года и интегрированный в JDK 11, ZGC является масштабируемым сборщиком мусора с низкой задержкой. ZGC был представлен в качестве экспериментальной опции, потому что разработчики Java решили, что функцию такого размера и сложности нужно вводить осторожно и постепенно. С тех пор был добавлен ряд улучшений, начиная от параллельной выгрузки классов, раскомментирования неиспользуемой памяти и поддержки совместного использования данных классов до улучшения осведомленности NUMA и предварительного обращения к многопоточной куче. Вдобавок с четырех терабайт до 16 терабайт был увеличен максимальный размер кучи. ZGC решает проблемы производительности в приложениях с большими объемами данных, например в машинном обучении, где пользователи хотят быть уверены, что обработка данных не будет подвержена непредсказуемости или длительным паузам из-за сбора мусора. Поддерживаемые платформы включают Linux, Windows и MacOS.
• Текстовые блоки, предварительно представленные в JDK 14 и в JDK 13 предназначены для упрощения задачи написания программ Java, облегчающие написание строк, охватывающих несколько строк исходного кода, обычно избегая при этом escape-последовательностей. Текстовый блок — это многострочный литерал, позволяющий избегать необходимости в большинстве escape-последовательностей, автоматически форматирующий строку предсказуемым образом и предоставляющий при необходимости разработчику контроль над форматом. Цель введения текстовых блоков — повышение читабельности строк кода, написанного на языках, отличных от Java в Java-программах. Другая цель — поддержка миграции со строковых литералов, притом, что любая новая конструкция может выражать тот же набор строк, что и строковый литерал, интерпретировать те же escape-последовательности и управляться тем же способом, что и строковый литерал. Разработчики OpenJDK надеются добавить escape-последовательности для управления white-space и переходом на новую строку.
• Сборщик мусора c низкой задержкой Shenandoah станет производственной функцией и выйдет из экспериментальной стадии. Он был интегрирован в JDK 12 год назад.
• Удаление Nashorn, дебютировавшего в JDK 8 в марте 2014 года, но устаревшим из-за новых технологий, например, GraalVM. В OpenJDK 15 предложение предусматривает удаление Nashorn API и инструмента командной строки jjs, который используется для вызова формы редактирования.
• Объявление устаревшим механизма активации RMI для последующего удаления. Механизм активации RMI-это устаревшая часть RMI, которая была необязательной начиная с Java 8. Активация RMI накладывает постоянную нагрузку на техническое обслуживание. Другие части RMI не будут отменены.
Перевод Академии Progwards