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

Единственный ЯП, на котором бывает легко читаемый лапшекод.

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

это пропертя на самом деле метод» и «а тут мы на самом деле создаем экземпляр класса, а не вызываем метод, да и вообще это инфикс»

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

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

Tic tac toe апплет из детства перестал работать. Это удар ножом в спину!

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

Последняя версия Eclipse 2021 настолько глючная, что был вынужден был поставить взад последнюю самую стабильную версию Eclipse 2008

Ты наверняка троллишь, но вот завтра должна выйти новая версия Эклипса. Уже есть ролик, в котором они извиняются за неприятные баги в предыдущей версии, которые теперь исправили:

https://www.youtube.com/watch?v=_OkIpz__Fyk

Кстати, поддержку Java 17 туда по умолчанию ещё не подвезли, но предлагают доустановить какой-то плагин для этого.

hummer
()

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

В каком состоянии сейчас AOT в Java 17 ?

Есть какие-то сторонние компиляторы кроме Iodine?

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

Затем чтоб ты его не вздумал расширять, потому что это не нужно по задумке автора :) Примерно как в плюсах многие гении от std контейнеров пытаются наследоваться, потом огребают кучу проблем, чтоб героически их решать, вместо того чтоб композицию применять.

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

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

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

anonymous
()

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

устаревший API OpenGL

WAT? Или этот Metal через вулкан рендерит?

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

Метал и есть тамошний вулкан, только не вулкан, а метал

anonymous
()

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

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

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

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

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

final в языке был изначально и он часто используется, в том числе в стандартной библиотеке. Так что это мнение разделяется далеко не всеми. Кто хочет — пускай делают открытые классы, кто хочет — закрытые.

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

Сенькс. Глянул по диагонали (поиском «destruct» и примеры). Вроде похоже на правду.

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

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

+1. Лично я люблю гайки закручивать. И очень часто потом приходится final убирать.

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

пользоваться и расширять — разные глаголы :) АПИ без классов расширять по своему никто не пробует, не имея такой возможности, произвольно меняя параметры сводных функций (очень надо — пишет свой слой оберток), а классы юзать так прям без наследования никак. Другое дело что в плюсах на все private, final можно при сильном желании болт ложить, но только на свой страх и риск. А так sealed или final просто показывает явно намеренья автора, которые некоторым «неочевидны» если их конпелятор не обругал.

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

Да пофиг на намерение автора, если класс открытый. Ну т.е. я дурак беру риски на себя, чего автору-то переживать?

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

Согласен, я тоже подумал, что это нечто среднее между javascript и java, потому, фронтендеры писаются от этого кипятком на андроиде. Причем ор стоит такой, что прям супер, на деле гавно. А если декомпилированные классы постом посмотреть, там адок.

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

Или потому, что проприетарную либу можно закрыть от расширения и доделывания? :)

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

LTS теперь будет каждые 2 года, а не три (пока это proposal, но скорей всего примут). Moving Java Forward Even Faster

Надеюсь не примут, всё-таки 2 года для джавы - слишком быстро. А если пропускать по одному LTS релизу, то обновление получится раз в 4 года, что слишком долго.

Я думаю тут дело в том, чтобы как можно быстрее переставать поддерживать LTS релиз, дабы клиенты переходили на платную подписку. Будет как в Федоре - поддерживается актуальный LTS + предыдущий. Как только новый LTS выходит, предыдущий перестаёт поддерживаться спустя месяц-два, разве что за деньги можно получить патчи.

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

Хороший вопрос на самом деле

Retain the experimental Java-level JVM compiler interface (JVMCI) so that developers can continue to use externally-built versions of the compiler for JIT compilation.

Оставили JVMCI в jdk, но что б насладиться graalvm нужно качать отдельно (у него даже версионирование своё, оказывается)

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

А что, там уже сделали что-то, что может наметопрограммировать кучу однотипный сеттеров? Или опять нужно позориться с кодогеном из иде?

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

Мне интересно, что быстрее жаба или питон ныне ?

Ты наркоман?

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

С таким успехом, а нафиг питон нужен?

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

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

нафиг python нужен

  • скорость далеко не всегда нужна, мне всегда хватало скорости змеек.
  • java много лишнего кода
  • на змейках гораздо удобнее писать скрипты написал запустил и забыл.
XoFfiCEr ★★☆☆
()
Последнее исправление: XoFfiCEr (всего исправлений: 1)
Ответ на: комментарий от olelookoe

У причастных софт на жаба 8 и они в гробу видали какие-то там миграции. В особых случаях, даже с одной сборки 8-й жабки на другую.

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

GraalVM есть отдельным проектом. Качаешь и пользуешь. То, что там были какие-то куски в JDK я не знал и остальные видимо тоже.

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

Здрасссти.. «Не читал, но осуждаю»?

  • sealed в C# - это final в Java,
  • sealed в Java - это case-классы в Scala (я предполагаю).
n-dimens
()
Ответ на: комментарий от GP

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

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

Донельзя правильный вопрос. Жаль, донести до менеджмента технологических корпораций его сложно.

Несколько лет назад хипстеры протолкнули пистон куда можно и куда нельзя, а теперь разгребаем…

Главный контраргумент «ну куча кода написано, не переписывать же?». Причём речь обычно о втором пистоне, не о третьем (если уж выбирать из двух зол, выбирал бы третий, там хоть сахарка побольше).

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

Оно жрет память больше электрона. Swing норм с темой от idea. На офтопике 58 МБ памяти жрет гуй на Swing для ККТ с подключением к MSSQL.

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

В каком состоянии сейчас AOT в Java 17 ?

Можно собирать жирные бинари под x64, включая армы, используя Graal Native. Под 32 бита ничего нет.

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

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

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

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

Насколько помню, Swing сидит на шее AWT, так что специально под вяленого свинг не надо допиливать.

Хотя может и ошибаюсь.

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

Нормальный паттерн матчинг это всегда хорошо.

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

JavaFX выкинули из JDK и он внезапно так взял да помер, как я и предполагал.

А вот помнится мне при обсуждении этой новости местные форумные Java-фанатики тут писали мол всё правильно, JDK тормозил развитие JavaFX, вот сейчас он будет отдельно и так взлетит, что с GTK+ и Qt начнёт конкурировать, а парни из JetBrains, Oracle и Eclipse Foundation перепишут свои IDE на этот фреймворк.

А по факту чуда не случилось: GUI для легковесного дистрибутива (комментарий)

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

Я чушь не несу. Несешь ее ты.

У Eclipse RCP/SWT просто нет альтернатив в тырпрайс сегменте.

На этом вашем свинге пишутся мелкие одноформенные утилитки.

Серьезные приложения уровне УППыря - SWT Only

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