Випуск Java SE 16

Після шести місяців розробки компанія Oracle випустила платформу Java SE 16 (Java Platform, Standard Edition 16), як еталонну реалізацію якої використовується відкритий проект OpenJDK. У Java SE 16 збережено зворотну сумісність з минулими випусками платформи Java, всі раніше написані Java-проекти без змін будуть працездатні при запуску під керуванням нової версії. Готові для встановлення складання Java SE 16 (JDK, JRE та Server JRE) підготовлені для Linux (x86_64, AArch64), Windows та macOS. Розроблена в рамках проекту OpenJDK еталонна реалізація Java 16 повністю відкрита під ліцензією GPLv2 з винятками GNU ClassPath, що дозволяє динамічне зв'язування з комерційними продуктами.

Java SE 16 віднесено до категорії випусків із звичайним терміном підтримки, оновлення для якого будуть випускатися до наступного випуску. Як гілка з тривалим терміном підтримки (LTS) слід використовувати Java SE 11, оновлення для якого будуть випускатися до 2026 року. Наступний LTS-реліз заплановано на вересень 2021 року. Нагадаємо, що починаючи з випуску Java 10 проект перейшов на новий процес розробки, який передбачає більш короткий цикл формування нових релізів. Нова функціональність тепер розвивається в одній master-гілці, що постійно оновлюється, в яку включаються вже готові зміни і від якої раз на шість місяців відгалужуються гілки для стабілізації нових випусків.

Під час підготовки нового випуску розробка переведена із системи управління версіями Mercurial на Git та платформу спільної розробки GitHub. Очікується, що міграція дозволить підвищити продуктивність операцій із репозиторієм, збільшити ефективність зберігання, забезпечити доступ до змін за всю історію проекту, покращити підтримку рецензування коду та задіяти API для автоматизації робочих процесів. Крім того, застосування Git та GitHub робить проект більш привабливим для новачків та розробників, які звикли до Git.

З нововведень Java 16 можна відзначити:

  • Доданий експериментальний модуль jdk.incubator.vector з реалізацією API Vector, що надає функції векторних обчислень, які виконуються з використанням векторних інструкцій процесорів x86_64 і AArch64 і дозволяють одночасно застосувати операції відразу до кількох значень (SIMD). На відміну від можливостей з автовекторизації скалярних операцій, що надаються в JIT-компіляторі HotSpot, новий API дозволяє явно керувати векторизацією для паралельної обробки даних.
  • У коді JDK і VM HotSpot, написаному на C++, можна використовувати можливості, що з'явилися в специфікації C++14. Раніше допускали використання стандартів C++98/03.
  • У збирач сміття ZGC (Z Garbage Collector), який працює в пасивному режимі і наскільки це можливо мінімізуючий затримки через складання сміття, додана можливість паралельної обробки стеків потоків без припинення виконання потоків програми. У ZGC тепер залишилися лише вимагають припинення роботи, які мають постійні затримки, які зазвичай не перевищують кількох сотень мікросекунд.
  • У класах SocketChannel, ServerSocketChannel та java.nio.channels додано підтримку Unix-сокетів (AF_UNIX).
  • Реалізовано порт для Linux-дистрибутива Alpine зі стандартною Сі-бібліотекою musl, який популярний в оточеннях для контейнерів, мікросервісів, хмарних систем, що вбудовуються. Запропонований порт у подібних оточеннях дозволяє виконувати програми на Java як звичайні програми. Крім того, за допомогою jlink можна прибрати всі модулі, що не використовуються, і сформувати мінімальне оточення, достатнє для виконання програми, що дозволяє створювати специфічні для конкретних додатків компактні образи.
  • Реалізовано механізм Elastic Metaspace, що оптимізує операції виділення та повернення пам'яті, займаної метаданими класів (metaspace) у JVM HotSpot. Застосування Elastic Metaspace знижує фрагментацію пам'яті, зменшує накладні витрати в завантажувачі класів, а також благотворно впливає на продуктивність серверних додатків, що тривало виконуються, за рахунок швидшого повернення операційній системі пам'яті, яку займають невикористані метадані класів. Для вибору режиму вивільнення пам'яті після вивантаження класів запропоновано опцію «-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)».
  • Додано порт JDK для систем Windows, що працюють на обладнанні з процесорами на базі архітектури AArch64.
  • Запропоновано третій попередній варіант API Foreign-Memory Access, що дозволяє Java-додаткам безпечно та ефективно отримати доступ до областей пам'яті, поза купою Java, маніпулюючи новими абстракціями MemorySegment, MemoryAddress та MemoryLayout.
  • Реалізовано експериментальний API Foreign Linker, що надає доступ із Java до нативного коду. Разом з API Foreign-Memory новий програмний інтерфейс помітно спрощує створення обв'язок над звичайними бібліотеками, що розділяються.
  • Додано утиліту jpackage, що дозволяє створювати пакети для самодостатніх (self-contained) Java-додатків. Утиліта базується на javapackager з JavaFX і дозволяє формувати пакети у форматах, рідних для різних платформ (msi та exe для Windows, pkg та dmg для macOS, deb та rpm для Linux). Пакети включають усі необхідні залежності.
  • За умовчанням включена строга інкапсуляція всіх внутрішніх елементів JDK, за винятком критичних API, таких як sun.misc.Unsafe. Значення опції «illegal-access» тепер за умовчанням виставлено в «deny» замість «permit», що призведе до блокування спроб звернення з коду до більшості внутрішніх класів, методів та полів. Для обходу обмеження слід використовувати опцію "-illegal-access = permit".
  • Стабілізовано реалізацію зіставлення зі зразком в операторі «instanceof», яка дозволяє відразу визначити локальну змінну для звернення до перевіреного значення. Наприклад, можна відразу писати "if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}" без явного визначення "String s = (String) obj". Було: if (obj instanceof Group) {Group group = (Group) obj; var entries = group.getEntries(); } Тепер можна обійтися без визначення "Group group = (Group) obj": if (obj instanceof Group group) { var entries = group.getEntries(); }
  • Стабілізовано реалізацію ключового слова «record», що надає компактну форму для визначення класів, що дозволяє обійтися без явного визначення різних низькорівневих методів, таких як equals(), hashCode() і toString(), у випадках, коли дані зберігаються тільки в полях, поведінка роботи з якими не змінюється. Коли в класі використовуються типові реалізації методів equals(), hashCode() і toString(), в ньому можна обійтися без їхнього явного визначення: public record BankTransaction

    Це оголошення призведе до автоматичного додавання реалізацій методів equals(), hashCode() і toString() на додаток до конструктора та методів, що контролюють зміну даних (getter).

  • Запропоновано другий попередній варіант запечатаних (sealed) класів та інтерфейсів, які не можуть використовуватися іншими класами та інтерфейсами для успадкування, розширення або перевизначення реалізації. Запечатані класи також надають більш декларативний спосіб обмеження використання суперкласу, ніж модифікатори доступу, що базуються на явному перерахуванні підкласів, дозволених для розширення. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {…}

Джерело: opennet.ru

Додати коментар або відгук