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 ()

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

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

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

говнокод

это отсюда экзампл, и как бы он не претендует.

мне интересно прост, будет работать compile-time проверка в type switch или нет.

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

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

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

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

Legioner ★★★★★ ()
Ответ на: комментарий от 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 ★★★★ ()
Ответ на: комментарий от GP

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

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

Он у них version specific.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yilativs ★★★ ()