LINUX.ORG.RU

Java 17 LTS

 , ,


0

0

Состоялся релиз Java 17 с расширеной поддержкой (LTS). Предыдущая версия с расширеной поддержкой, Java 11, вышла в 2018 году.

Наиболее примечательным изменением в данной версии является то, что поддержка «запечатаных» (sealed) классов и интерфейсов вышла из стадии предварительного просмотра и признана готовой к использованию.

Запечатанные (sealed) типы — это классы или интерфейсы, накладывающие ограничения на другие классы или интерфейсы, которые могут расширять или реализовывать их. Для объявления запечатанного класса или интерфейса используется модификатор sealed. Список подтипов может быть перечислен при объявлении запечатанного класса или интерфейса после ключевого слова permits. В случае если подтипы находятся в том же пакете или модуле, компилятор сам может вывести список подтипов и permits в объявлении запечатанного класса или интерфейса можно опустить.

sealed interface Color permits BiColor, TriColor { }
	
record BiColor(int r, int g, int b) implements Color {}
record TriColor(int r, int g, int b) implements Color {}

Реализованы спецификации:

  • JEP 306: Restore Always-Strict Floating-Point Semantics
    Операции с плавающей запятой теперь будут постоянно строгими, вместо того чтобы иметь как строгую семантику с плавающей запятой (strictfp), так и слегка отличающуюся семантику с плавающей запятой по умолчанию.

  • JEP 356: Enhanced Pseudo-Random Number Generators
    Создан новый интерфейс RandomGenerator и реализации для генераторов псевдослучайных чисел (PRNG): SplittableRandomGenerator, JumpableRandomGenerator, LeapableRandomGenerator, ArbitrarilyJumpableRandomGenerator.

  • JEP 382: New macOS Rendering Pipeline
    Добавлен новый конвейер рендеринга для macOS, использующий API Metal, в качестве альтернативы существующему конвейеру, использующему устаревший API OpenGL.

  • JEP 391: macOS/AArch64 Port
    Реализовано выполнение Java-кода на базе инструкций AArch64 без использования Rosetta 2.

  • JEP 398: Deprecate the Applet API for Removal
    Applet API помечен на удаление и будет удалён в последующих релизах.

  • JEP 403: Strongly Encapsulate JDK Internals
    Полностью убрана возможность ослабить строгую инкапсуляцию внутренних частей JVM; параметр --illegal-access, позволявший это сделать в предыдущих версиях, удалён.

  • JEP 406: Pattern Matching for switch (Preview)
    Реализован редварительный просмотр Pattern Matching для конструкции switch.

  • JEP 407: Remove RMI Activation
    Механизм активации RMI удалён.

  • JEP 409: Sealed Classes
    Запечатанные классы или интерфейсы ограничивают доступ к их расширению или реализации посредством явного указания классов/интерфейсов которым это разрешено.

  • JEP 410: Remove the Experimental AOT and JIT Compiler
    Удалена экспериментальная поддержка АОТ-компилятора.

  • JEP 411: Deprecate the Security Manager for Removal
    Security Manager помечен как устаревший и будет удалён в последующих версиях вместе с Applet API.

  • JEP 412: Foreign Function & Memory API (Incubator)
    Улучшены два ранее созданных API: Foreign-Memory Access API и Foreign Linker API.

  • JEP 414: Vector API (Second Incubator)
    Вторая версия для предварительного просмотра, где была улучшена производительность и реализация Vector API, включая улучшения преобразования байтовых векторов в логические массивы из них.

  • JEP 415: Context-Specific Deserialization Filters
    Добавлена настраиваемая фабрика фильтров для всей JVM. Эти фильтры являются динамическими и зависят от контекста, в отличие от единственного статического фильтра десериализации для всей JVM. Для обратной совместимости, если фабрика фильтров не задана, встроенная фабрика возвращает статический фильтр для всей JVM, если он был настроен.

>>> Подробности

★★★★☆

Проверено: xaizek ()
Последнее исправление: cocucka (всего исправлений: 8)

Переименовали бы ужо. Сие Ораклёвое поделие мало имеет отношения к ламповой Sun Java :D :D :D :D.

vtVitus ★★★★★
()
Ответ на: комментарий от cocucka

Но мне они не нужны. Это же pojo, а не полноценный класс. А если надо какой-то сеттер переназначить? Это затыкание жопы пальцем. Давно нужен инструмент для метапограммирования классов, а не убогие затычки. Кококо, ынтерпрайз язык, да только такой бездарный, что приходится делать ломбок-костыли.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от Shadow

Лучшие практики JS говнокода теперь и на JVM!

А нечего писать на JS, как на Java! Многие страдал от названий. Java != JS

B0B
()
Ответ на: комментарий от crutch_master

А кто отрицает? Пиши и страдай! Мы же о мазохизме?

B0B
()
Ответ на: комментарий от crutch_master

Программист на фортране может писать на фортране на любом языке.

Эээээээээээээ …

Программист на Java может писать на Java на любом языке.
anonymous
()
Ответ на: комментарий от anonymous

А где Метанпрог?

У него программа рисуется и модуль называется ПОЛОТНО!

anonymous
()
Ответ на: комментарий от anonymous

И это хорошо. Симфони написана программистами Джава.

GP
()

Попробовал я тут недавно go. Теперь на java работать больно. И не понятно, зачем нужна java, когда уже есть go.

untitl3d
()
Ответ на: комментарий от slackwarrior

Другое дело что в плюсах на все private, final можно при сильном желании болт ложить, но только на свой страх и риск.

В плюсах final позволяет девиртуализировать и, как следствие, инлайнить виртуальные методы. Что особенно проявляется, когда собираешь с lto и компилятор знает, что никаких других экземпляров нет.

anonymous
()
Ответ на: комментарий от cocucka

Зачем сеттер переназначать?

А зачем тогда вообще сеттер нужен, если его все равно никто никогда не будет переназначать?

Это попахивает неправильным ооп.

Нарываешься на еще один ООП-срач?

crutch_master ★★★★★
()
Ответ на: комментарий от GP

Ты хочешь разглашения NDA 100 топовых банков мира?

Которую они, надо полагать, все подписали с тобой?

ptarh ★★★★★
()
Ответ на: комментарий от Legioner

Кто хочет — пускай делают открытые классы, кто хочет — закрытые

К сожалению не всех, кто делает закрытые классы можно найти и отпипоругать.

ya-betmen ★★★★★
()
Ответ на: комментарий от XoFfiCEr

Если шуруповёрт закручивает саморезы быстрее, то зачем нужен молоток?

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

shpinog ★★★
()
Ответ на: комментарий от XoFfiCEr

скорость далеко не всегда нужна, мне всегда хватало скорости змеек.

Далеко не всегда нужна, звучит как будто она бывает лишней.

java много лишнего кода

В скриптах всегда относительно мало когда, если в скрипте много кода - это уже велосипед.

на змейках гораздо удобнее писать скрипты написал запустил и забыл.

Всё что угодно можно написать, запустить и забыть, сомнительный критерий удобства.

shpinog ★★★
()
Ответ на: комментарий от i3draven

Только после этого я понял насколько «консвервативность» джава инженеров это хорошо

Котлины и прочие поделки изобретают не от хорошей жизни. Ява застывшее говно мамонта, которое уже в начале нулевых безумно устарело (с выходом расово верного .NET).

anonymous
()
Ответ на: комментарий от vtVitus

И что в ней поменялось? Java как java.

anonymous
()
Ответ на: комментарий от anonymous

Смачно пукнул безработный делфи прогер

GP
()
Ответ на: комментарий от anonymous

На странице загрузки пишут, что доступно бесплатно для всех и вся. Выходит снова поменяли лицензию?

Да, именно так.

https://blogs.oracle.com/cloud-infrastructure/post/introducing-free-java-license

  • Oracle is making the industry leading Oracle JDK available for free, including all quarterly security updates. This includes commercial and production use.
  • The new license is the «Oracle No-Fee Terms and Conditions» (NFTC) license. This license for the Oracle JDK permits free use for all users, even commercial and production use. Redistribution is permitted as long as it is not for a fee.
  • Developers and organizations can now easily download, use, share and redistribute the Oracle JDK without needing a click-through.
  • Oracle will provide these free releases and updates starting with Oracle JDK 17 and continue for one full year after the next LTS release. Prior versions are not affected by this change.
  • Oracle will continue to provide Oracle OpenJDK releases under the GPL on the same releases and schedule as it has since Java 9.
hummer
()
Ответ на: комментарий от crutch_master

В кваркусе прикольно сделали. Там делаешь

public class Person {
    public String lastName;

    public void setLastName(lastName) { ... }
}

person.lastName = "123"; // переписывается на person.setLastName("123")

А вообще я давно хочу сделать свою генерилку бинов.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Когда котлин изобретали, это действительно было так. Тогда была много лет Java 6 и выпустили Java 7, в котором изменений было кот наплакал и опять всё застыло. С тех пор оракл нормально жаву ускорил, изменений очень много. Не думаю, что сегодня стали бы делать котлин.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner
переписывается на person.setLastName("123")

Ну охренеть. Сначала оно делает не то, что написано, а потом эти люди рассказывают про 1 + "2"

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Ага, для непосвящённого будет прикольно.

Legioner ★★★★★
()
Ответ на: комментарий от GP

Почему я его до сих пор не вижу через Check for Updates из Eclipse 2021.06?

Наверное потому, что он у тебя как-то неправильно настроен?

hummer
()
Ответ на: комментарий от hummer

Прекрасная архитектура у системы обновлений ыглибза.

То есть update sites 2 недели назад для обновления с 2019 до 2021-06 были правильно настроены и обновили систему.

А сейчас эти настройки update sites стали вдруг недействительными.

Офигеннейшая орхедегдура у самой лучшей жаба IDE. IntelliJ IDEA, учитесь!

GP
()
Ответ на: комментарий от GP

Ну зачем мне гадать? Зайди в свои настройки и посмотри сам.

У IntelliJ IDEA бывают свои приключения во время обновления. Ксати интересно, они останутся на corretto JDK от Amazon или вернутся на теперь уже free Oracle JDK?

hummer
()
Ответ на: комментарий от ya-betmen

Сама идея запрещать наследоваться от класса это маразм.

why so serious?

    public static double getPerimeter(Shape shape) throws IllegalArgumentException {
        if (shape instanceof Rectangle r) {
            return 2 * r.length() + 2 * r.width();
        } else if (shape instanceof Circle c) {
            return 2 * c.radius() * Math.PI;
        } else {
            throw new IllegalArgumentException("Unrecognized shape");
        }
    }

vs.

    public static double getPerimeter(Shape shape) {
        if (shape instanceof Rectangle r) {
            return 2 * r.length() + 2 * r.width();
        } else if (shape instanceof Circle c) {
            return 2 * c.radius() * Math.PI;
        }
// хз, будет ли тут missing return statement
// не на чем проверить оно работает нормально или нет.
    }
drsm ★★
()
Ответ на: комментарий от pinus_nigra

Лучше ещё пару лет можно не дёргаться.

anonymous
()
Ответ на: комментарий от pinus_nigra

Можешь забашлять Ларри и не дергаться до 2030.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Действительно, 🤮.

Вообще getPerimeter должен быть у shape, виртуальный. Не вижу здесь даже необходимости в double virtual dispatch…

anonymous
()

Стареем, вон Java 17 уже LTS.

А дальше что, Google+ закроют?

vertexua ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.