Третья LTS-версия JDK, JDK17, здесь

Java задняя часть Архитектура
Третья LTS-версия JDK, JDK17, здесь

«Это 14-й день моего участия в ноябрьском испытании обновлений. Подробную информацию об этом событии см.:Вызов последнего обновления 2021 г."

Введение

JDK17 был выпущен в сентябре 2021 года, а JDK17 — это последняя LTS-версия. Так называемая LTS-версия — это версия, которая может получить поддержку продукта не менее восьми лет. От JDK8 в 2014 году до JDK11 в 2018 году, а затем до JDK17 в 2021 году.

В то же время Oracle также скорректировала период выпуска LTS-версии с предыдущих трех лет до текущих двух лет, а это означает, что следующей LTS-версией будет JDK21, вау!

А что, если это не LTS-версия? Не-LTS-версия получит только шесть месяцев поддержки продукта. Поэтому мы по-прежнему используем LTS-версию.

Итак, давайте взглянем на новые возможности JDK17.

Новые функции в JDK17

Всего JDK17 предоставляет 14 точек оптимизации или точек изменения. Мы объясним их один за другим.

новые языковые возможности

Новая языковая функция JDK17 — это только один JEP 409: запечатанные классы.

Sealed Classes — это концепция, представленная в JDK15, которая указывает, какие классы классу разрешено наследовать от него:

public sealed class SealExample permits Seal1, Seal2{
}

public non-sealed class Seal1 extends SealExample {
}

public final class Seal2 extends SealExample {
}

final означает, что Seal2 больше не может быть унаследован. незапечатанный означает, что любому классу может быть позволено наследовать.

Оптимизация основной библиотеки

JDK17 имеет четыре оптимизации для базовой библиотеки JAVA.

  • Первый: JEP 306: восстановить всегда строгую семантику с плавающей запятой.

Что это? Проще говоря, это предыдущая аппаратная архитектура, потребляющая много ресурсов при вычислениях строго с семантикой с плавающей запятой. Это было невыносимо, когда аппаратный уровень давным-давно не был высоким.

Таким образом, после JDK1.2 семантика с плавающей запятой была точно настроена, а строгая семантика с плавающей запятой по умолчанию была изменена.

Но на дворе уже 2021 год, и аппаратный уровень развивается стремительно, поэтому модификация, представленная ранее, не нужна и от нее отказались в JDK17.

  • Второй: JEP 356: усовершенствованный генератор псевдослучайных чисел.

В JDK есть класс java.util.Random, который генерирует случайные числа, но этот класс генерирует псевдослучайные числа.

JDK17 расширил этот класс, чтобы предоставить интерфейс RandomGenerator, который предоставляет унифицированный API для всех псевдослучайных чисел.

RandomGenerators предоставляет такие методы, как ints, longs, doubles, nextBoolean, nextInt, nextLong, nextDouble и nextFloat для генерации соответствующих случайных чисел.

Интерфейс RandomGenerator включает в себя 4 подинтерфейса, а именно:

SplittableRandomGenerator: предоставляет методы split и splits, позволяющие пользователю создавать новый RandomGenerator из существующего RandomGenerator.

JumpableRandomGenerator: расширяет методы jump и jumps RandomGenerator, позволяя пользователям пропускать определенное количество случайных чисел.

LeapableRandomGenerator: расширяет методы скачка и скачка RandomGenerator, позволяя пользователям пропускать большое количество случайных чисел.

ArbitrouslyJumpableRandomGenerator: расширяет LeapableRandomGenerator, позволяя пользователям указывать пропущенные случайные числа.

Также рефакторинг таких классов, как Random, ThreadLocalRandom и SplittableRandom.

  • Третий — JEP 382: новый конвейер рендеринга macOS.

Это специально оптимизировано для Mac с использованием новейшего API Apple Metal для достижения 2D-рендеринга в JAVA.

  • Четвертый — JEP 415: Контекстно-зависимые фильтры десериализации.

Очень опасным использованием в JDK является десериализация, потому что вы не знаете, является ли десериализованный объект опасным объектом.Проверьте поток данных перед компиляцией.

Но у этого потокового фильтра есть несколько ограничений, такой подход не масштабируется, и сложно обновить фильтр после выпуска кода. Он также не может фильтровать операции десериализации, выполняемые сторонними библиотеками в приложении.

Для решения этих проблем JEP 290 также представляет фильтр десериализации для всей JVM, который можно установить с помощью API, системных свойств или свойств безопасности. Однако такие статические фильтры часто не подходят для сложных приложений с несколькими контекстами выполнения, поскольку для разных контекстов могут требоваться разные условия фильтрации.

В JDK17 улучшен метод фильтрации JDK9, а контекстно-зависимые фильтры десериализации можно настроить в области JVM.

Поддержка новых платформ

  • JEP 391: macOS AArch 64 Port

Чип M1 для Mac выпущен уже давно, и нет никаких причин, по которым JDK его не поддерживает.Этот JEP должен позволить JDK17 поддерживать новую архитектуру Apple Arm 64.

Функции предварительного просмотра

  • JEP 406: Pattern Matching for switch (Preview)

Эта новая функция позволяет использовать сопоставление с шаблоном в коммутаторе.

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

// Old code
if (o instanceof String) {
    String s = (String)o;
    ... use s ...
}

// New code
if (o instanceof String s) {
    ... use s ...
}

Но если экземпляров слишком много, это тоже вызовет проблемы:

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

Лучший способ — превратить приведенный выше код в переключатель:

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

Это сопоставление с образцом в коммутаторе.

  • JEP 412: Foreign Function and Memory API (Incubator)

В JDK14 и 15 JDK может вызывать код, не принадлежащий JVM, и обращаться к пространству памяти, не находящемуся под юрисдикцией JVM. Эта новая функция была улучшена в JDK17.

Представьте, что JDK сможет в будущем нативно поддерживать вызовы API на языках, отличных от Java, разве это не удивительно?

  • JEP 414: Vector API (Second Incubator)

Вектор был представлен в JDK16. Это может ускорить вычисление векторов. Расчет обхода цикла можно упростить с помощью Vector.

другие изменения

Некоторые другие изменения, такие как инкапсуляция API, используемого внутри JDK, отказ от Security Manager, Applet API и RMI и т. д., здесь представлены не будут.

Суммировать

JDK17 — это LTS-версия, а также предоставляет множество отличных новых функций, поэтому не спешите использовать ее!

Эта статья была включена вWoohoo Freudpress.com/27-JDK17-а как насчет…

Самая популярная интерпретация, самая глубокая галантерея, самые краткие уроки и множество трюков, о которых вы не знаете, ждут вас!

Добро пожаловать, чтобы обратить внимание на мой официальный аккаунт: «Программируйте эти вещи», разбирайтесь в технологиях, лучше поймите себя!

Категории