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)

Ответ на: комментарий от Legioner

В книге по котлин так на каждой странице и писали «Котлин гараздо круче чем java 6» :) Только уже в момент выхода 8 джавы котлиновские потуги были бесполезны, они там напридумывали то, что в джаве есть например asSequence и прочее подобное. Мало того, книжка учит, что надо использовать терминальные операции вместо…хотя пофиг. В общем да, котлин боролся с давно устаревшей джавой версии 6.

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

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

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

По if-ам не будет. Так будет:

    public static double getPerimeter(Shape shape) {
        return switch(shape) {
            case Rectangle r -> 2 * r.length() + 2 * r.width();
            case Circle c -> 2 * c.radius() * Math.PI;
        };
    }
Legioner ★★★★★
()
Ответ на: комментарий от hummer

Ещё раз: с теми же настройками был успешно произведен апдейт с Eclipse 2019 на 2021-06.

Сегодня целый день проверял - 2021-09 нет

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

Сейчас на 11 жаве уже больше приложений, чем на 8. С 11 до 17 мигрировать относительно несложно. На 8 тоже вряд ли многие будут сидеть очень долго. Так что я бы про ничтожные шансы не зарекался.

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

Дело не в сложности, а в самом факте необходимости переезда. Это ж проект, бюджет, ресурсы. А дедлайны как обычно вчера.

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

Проблема Котлина и других язычков на базе JVM в том, что Жабу все-равно нужно знать. От нее никак не избавиться, на ней написаны почти все библиотеки и фреймворки и выходит что вместо одного языка, тебе приходится знать оба.

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

Поддержка старой жавы тоже денег стоит. Недовольство программистов, не желающих устаревать на рынке труда тоже по сути денег стоит. На Java 1.4 нынче проектов особо не осталось, хотя с такой логикой их должно было бы быть предостаточно.

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

Это не проблема, котлин это надмножество над Java, если человек осилил Kotlin или Scala то по наитию сможет понять код на java не изучая его. А вот с clojure конечно будут проблемы, кодерам привыкшим к процедурное-алгоритмическим языкам тяжело понять функциональный язык да еще на s-expression, но и LISP кодерам тоже тяжело понять java, даже автор clojure не осилил ООП, правда это было 10 лет назад когда он в этом прямо заявил на претензии по поводу его кода на java. За 10 лет он наверное проникся.

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

Уважаемый эксперт по архитектуре ыглыбза - вам двойка.

Нужно для каждого нового релиза изменять update site url.

Он у них version specific.

Зы. А когда они завезут для немецких раскладок клавиатур поддержку «Toggle Comment» через хоткей?

Я за 20 лет не вижу прогресса в этой очень важной части написания кода.

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

Котлин позволяет создать свой DSL, т.е. писать код проблемно ориентированный, это не всегда нужно, но когда нужно это просто кил фича. На Java такой код читается плохо, пишется тоже очень плохо и ide не помогает писать код из-за обилия «import static», достаточно рассмотреть JOOQ или Mockito. А «import static» делается чтоб код сделать хоть немного компактнее и легче для восприятия.

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

Я думаю использование Kotlin/Scala в больших командах может превратиться в ад, с другой стороны над приложениями для andorid по моим представлениям обычно трудятся 1-2 кодера. Небольшим командам легко выработать общий стиль, для двух человек даже не проблема читать код друг-друга, даже если они будут писать по разному.

Я для своих проектов использую Kotlin, но у меня есть некоторые опасения попасть в команду пишущую на kotlin и тем более я бы не хотел попасть в бодишоп (в укоренившимся понимании этого слова), в такой агломерации уровень кодеров очень разный и ревьювить твой код там будут совершенно разные люди.

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

Каким образом это проблема? Все эти котлины сделаны в первую очередь для джавистов. Ну и джава язык несложный.

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

Уважаемый эксперт по архитектуре ыглыбза - вам двойка.

Нужно для каждого нового релиза изменять update site url.

Он у них version specific.

Тебе двойка за игнорирование мной сказанного выше о конфигурации обновлений.

Зы. А когда они завезут для немецких раскладок клавиатур поддержку «Toggle Comment» через хоткей?

Я за 20 лет не вижу прогресса в этой очень важной части написания кода.

Спроси их сам.

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

Тут 3/4 форума за С топят, а ты про устаревание на рынке труда…

«Кажется смешным, но люди берут». Наверное так комфортнее, иметь rhel 6 и древнюю Яву за бешеные бабки… С другой стороны, если работает, а от апгрейда банк крякнется, будет дороже.

И это мы ещё Кобол не обсуждали…

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

Спроси их сам

Вот мы и попались. Я теперь точно знаю, что ты не живешь в Германии. Немецкие Eclipse Java кодеры используют с 2004го года комбинацию Strg+7

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

В долгоиграющем сервисе у тебя жабий сборщик мусора положит весь сервис, если вовремя такой сервис не перезапускать

А долгоиграющий - это сколько? У меня за последние 190 дней аптайма ничего не легло пока что (да и то перезапускал только из-за обновления). Перед тем - было около полутора лет аптайма.

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

В долгоиграющем сервисе у тебя жабий сборщик мусора положит весь сервис, если вовремя такой сервис не перезапускать

Во времена монолитов все было нормально, по мере работы приложения уровень потребления памяти стабилизировался и не рос. GC показывал обычную «пилу» на графиках потребления. Утечка могла быть разве только от кривого использования ThreadLocal или HashMap. А так все работало месяцами до нового релиза.

Но вот перезапустить отдельно веб сервис без перезапуска того же Tomcat было чревато, утекал permgen space. Но это конечно мелкая неприятность, просто нужно было знать что не все фичи одинаково полезны.

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

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

Ватсон без трубки уже не мог

Так вот почему у тебя так долго не получалось.

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

OK, следующая версия Java 18 будет называться Visual Oracle Cobol With Objects 18

Grand Oracle With Natural Objects — сокращение доставляет!

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

Я как-то запускал гуй на жабе, это было больно.

На python Gui-и намного тормознее.

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

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

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

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

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

гм. у мну полно случаев с работающим оборудованием, хотящим 1.7 и (местами) даже 1.6 типичный пример - Brocade 300 и VNX.

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

ничего не скажет для англоязычного. Вот Super Hyper Intelligent java Translator - это да!

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

В принципе, да.

Но, даже, если и не подписали: почему ты до сих пор задаешь вопросы уровня школоло? Eclipse RCP/SWT выстрелил в тырпрайсе в те времена, когда свинг какаля и писался в подгузники. Именно RCP/SWT и захавал весь корпоративный сегмент.

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

java использует подход - дай пионерам в других языках набить шишек и внедряет только действительно полезные фичи - это позволяет ей иметь хорошую обратную совместимость до версии 1.0 (привет пистону и шарашке), а также всегда быть stable и up2date.

Yilativs ★★★★
()
9 декабря 2021 г.
Ответ на: комментарий от anonymous

Человек хочет вместо полей класса атрибуты класса (aka properties в терминологии c#), т.е. это как поля класса хранящие состояние объекта но такие же нормальные члены класса как методы: переопределяемые, с поздним связыванием и возможностью перехватывать обращения к ним посредством динамических прокси. Если бы было так то ненужно было бы генерировать set/get методы в бинах. Но Java создавалась давно и видно для скорости сделали как в c++, а из-за обратной совместимость переиграть не могут.

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

https://openjdk.java.net/jeps/409 сосиска вон для тебя даже специально ссылки на всю эту мишуру понавставлял, там на первом же развороте есть цели этого дела и пример когда это вдруг может понадобиться, не ленись )

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

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

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

Короче, что то же надо релизить из года в год, почему бы не это?

Как будто у них без этого работы нет. Коллекции например починить.

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

зачем ограничивать расширение существующего кода

Например в Scala это делают, чтобы гарантированно проверить все типы в паттерн-матчинге. Здесь скорее всего, за тем же.

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

их все устраивает, и новые языки типа котлина даже закладываются на эти коллекции в том виде что они есть, никто не будет ломать обратную совместимость просто так.

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

Я понимаю, что их устраивает, в том то и проблема, что чешут там где не чешется. Ну и один раз совместимоть они уже поломали.

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

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

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