LINUX.ORG.RU

Доступна новая версия Java SE 16

 ,


1

3

16 марта 2021 года компания Oracle объявила о выходе Java 16 (Oracle JDK 16), которая получила 17 новых усовершенствований платформы, призванных еще больше повысить производительность разработчиков.

Последняя версия JDK включает Pattern Matching for instanceof (JEP 394) и Records (JEP 395), предварительные версии которых появились в Java 14. Кроме того, разработчики смогут использовать новый инструмент упаковки jpackage (JEP 392) для сборки и распространения приложений, а также опробовать три инкубационные версии новых функций: Vector API (JEP 338), Foreign Linker API и Foreign-Memory Access API (JEP 389) и одну функцию предварительного просмотра Sealed Classes (JEP 397). В коде JDK и VM HotSpot, написанном на C++, теперь можно использовать возможности, появившиеся в спецификации C++14 (JEP 347).

Также стоит отметить появление порта для Linux-дистрибутива Alpine cо стандартной Си-библиотекой musl, который популярен в окружениях для контейнеров, микросервисов, облачных и встраиваемых систем (JEP 386).

При подготовке нового выпуска была проведена миграция с системы управления версиями Mercurial на Git и платформу для совместной разработки GitHub.

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

«Мощность шестимесячных интервалов выпуска была в полной мере продемонстрирована с последним выпуском», – говорит Жорж Сааб, вице-президент по развитию Java Platform Group, Oracle. «Pattern Matching и Records были представлены год назад в рамках JDK 14 и с тех пор прошли через несколько раундов обратной связи с общественностью, основанной на реальных сценариях использования. Этот процесс не только дал Java-разработчикам возможность поэкспериментировать с этими функциями до того, как они были доработаны, но и включил в себя ту критическую обратную связь, которая привела к двум отполированым JEP, которые действительно удовлетворяют потребности сообщества».

Релиз Java 16 является результатом общеотраслевой разработки, включающей открытый обзор, еженедельные сборки и обширное сотрудничество между инженерами Oracle и членами мирового сообщества Java-разработчиков через OpenJDK Community и Java Community Process.

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

★★★★★

Проверено: Shaman007 ()

Интересно, а оно когда-нибудь перестанет жрать и течь? Нет, я понимаю, что приложение можно ограничить параметрами памяти, что иногда даже соблюдается, но сама машина от этого течь не перестает же

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

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

anonymous ()

Для сборки ведроида достаточно до сих пор openJDK 9. Интересно, почему так, если уже 16ая версия и с каждым релизом все «производительнее».

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

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

anonymous ()

Векторное API, Alpine port, FFI. Все отличные изменения, молодцы.

(На Java не пишу)

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

Плохому кодеру ява тормозит. У семи сеньоров память течёт.

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

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

anonymous ()

Копипаста про Lombok:

Вчера сразу после выхода Java GA появился патч (https://github.com/rzwitserloot/lombok/commit/9806e5cca4b449159ad0509dafde81951b8a8523), который чинит этот баг. Ну как чинит, там опять обходные пути и сплошная грязь 💩. Но давайте по порядку, т.к. там немного нетривиально.

Итак, Lombok использует внутренности модуля jdk.compiler, так как ему для своего функционирования необходимо представление абстрактного синтаксического дерева Java и ещё много чего. Большая часть пакетов jdk.compiler модулем не экспортируется, и начиная с Java 16 доступиться до этих пакетов стало нельзя без использования флагов –illegal-access=permit или –add-opens. Можно было бы заставить пользователей руками передавать флаг javac -J–illegal-access=permit или -J–add-opens с перечислением 9 пакетов (com.sun.tools.javac.code, com.sun.tools.javac.comp…), но понятно, что такое решение максимум тянет на временный workaround. Поэтому был выбран другой путь: через reflection дёрнуть метод Module.addOpens() (https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/lang/Module.html#addOpens(java.lang.String,java.lang.Module)), передав туда наш модуль и имя пакета. Однако возникают следующие проблемы:

  1. Метод Module.addOpens() является CallerSensitive, и его может дёрнуть только код из самого модуля jdk.compiler, иначе вылетит IllegalCallerException. Что делать? Если посмотреть на реализацию метода Module.addOpens(), то можно увидеть, что он делегирует работу другому внутреннему методу Module.implAddOpens(), который уже не CallerSensitive. Поэтому давайте будем вызывать его!
  2. Но как вызвать внутренний метод, если теперь у нас внутренности JDK закрыты? Method.setAccessible(true) выбросит InacessibleObjectException. Что делать? Давайте попробуем сделать метод accessible через Unsafe! Сделать это можно так: в классе AccessibleObject (от которого отнаследован Method) есть поле boolean override. С помощью Unsafe это поле можно переключить с false на true, используя метод Unsafe.putBooleanVolatile. Давайте так и сделаем.
  3. Но не всё так просто. Чтобы вызвать putBooleanVolatile, нужно передать ему offset этого поля, получить который можно через другой метод Unsafe.objectFieldOffset.
  4. Вроде справились? Ещё нет. Чтобы вызвать Unsafe.objectFieldOffset, нужно иметь на руках объект Field для поля override. Но тут вроде всё просто? Получить Field можно просто вызвав AccessibleObject.class.getDeclaredField(«override»). Однако это не сработает: эту лавочку прикрыли в Java 12 (https://bugs.openjdk.java.net/browse/JDK-8210522) в целях безопасности, и поле override стало невидимым для reflection (чтобы кто попало не мог своими грязными ручонками вот так делать setAccessible, доступаясь до чего угодно: мы видите ли тут всё гайки закручиваем, а эти гады продолжают обходить и обходить).
  5. Так что же делать? И вот тут самое веселье (такой хак мне ни за что не пришёл бы в голову). Нам ведь нужно просто передать offset поля, а это просто обычный long. Давайте как-нибудь посчитаем, какой offset имеет это поле в объекте Method. Как? Очень просто: объявим где-нибудь на нашей стороне класс с точно такими же полями, как и у Method (и на всякий случай в том же порядке), и найдём offset boolean поля для этого класса (https://www.youtube.com/watch?v=VWoMoRBx2D8)! Как тебе такое, Илон Маск? Ну а что: есть два класса с одинаковыми полями – значит JVM должна разложить эти поля по оффсетам в этих двух классах идентично.

Вот такой вот хак. И это даже работает.

А теперь посмотрим ещё раз, какие допущения использовались, и как легко это всё может развалиться:

  1. В классе Module внутренний метод, отвечающий за логику открытия пакетов, называется implAddOpens. Если этот метод переименуют, добавят туда параметры или поменяют их порядок, Lombok сломается.
  2. Класс AccessibleObject имеет внутреннее boolean поле, которое объявлено первым. Если это поле уберут, на первое место поставят другое поле, JVM начнёт компоновать поля как-нибудь по-другому или вообще логика AccessibleObject как-нибудь совсем поменяется – Lombok сломается.
  3. А ещё, что есть Unsafe, который сам может когда-нибудь исчезнуть.

И ещё кстати это всё написано на Java 6, поэтому логика нахождения модулей, которая требует наличие таких классов как Optional, Module, ModuleLayer, реализована полностью через reflection.

ma1uta ★★★ ()
Последнее исправление: ma1uta (всего исправлений: 1)

Завезли Vector API. Теперь можно делать вот так:

var vc = va.mul(va).
                    add(vb.mul(vb)).
                    neg();

И оно будет при помощи SIMD параллелиться.

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

Или в ножки поклониться. Весь мир понимает что бойлерплейт не нужен, только душевнокобольные не унимаются.

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

этим клоунам еще с 8 версии говорили что джаву будут шатать, и любое недокументированное поведение может быть изменено, ссзб.

Ничего удивительного что пытаются починить через гланды, переписывать еще муторней.

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

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

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

с омерзительной восьмерки

Что в ней омерзительного?

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

Хз, хз. Мы на собесах специально спрашивали про отношение кандидата к ломбоку. Если он положительно о нём отзывался и не мог внятно аргументировать его необходимость (бойлерплейт не аргумент), то шёл искать работу в др. месте. Нам с такими не по пути.

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

Java это стандарт. Про совместимость с Windows Vista это уже к конкретным реализациям. Oracle OpenJDK с 15 версии совместим только с Server 2016 (и Win 10 соответственно). Azul собирает сборку для Server 2012 (и Win 7). А так ты можешь хоть для XP попробовать бэкпортировать, если умений хватит.

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

Хз, хз. Мы на собесах специально спрашивали про отношение кандидата к ломбоку. Если он положительно о нём отзывался и не мог внятно аргументировать его необходимость (бойлерплейт не аргумент), то шёл искать работу в др. месте. Нам с такими не по пути.

Ну а каков аргумент? Если завтра в класс добавят ещё одно поле, но забудут обновить equals(), hashCode(), toString() и конструктор - это разве не тот же самый аргумент? Или у вас предпочитают усидчивых шизофреников, которые всё это держат в голове и всегда обновляют вручную на автомате?

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

и @cocucka

Статический анализатор запускается не всегда и завязка на него скорее всего приведёт к завязке на DevOps. Код всё равно будет забит всем этим бойлерплейтом, делая его менее читабельным.

Разве Kotlin умеет всё то, что умеет Lombok? Там ведь не только гетеры - сетеры. Да и сетеры он может генерировать по-разному. Например @Accessors(chain = true).

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

Статический анализатор запускается не всегда

Wat? А когда он, блин, запускается? По четвергам? Смысл тогда в нём?

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

А аннотация через аннотацию в аннотации добавляет читабельности? Или если ты не видишь проблему, то её нет?

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

Разве Kotlin умеет всё то, что умеет Lombok?

Не могу ответить на твой вопрос. Я исхожу из позиции: зачем коверкать язык Lombok’ом, если можно просто сменить язык.

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

Альтернатива какой именно фиче? Если про геттеры-сеттеры, посмотри на Google AutoValue, мне нравится такой подход (хотя сама либа не совсем нравится, я планировал написать похожую, но слегка другую, но дальше планов не зашло).

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

Wat? А когда он, блин, запускается? По четвергам? Смысл тогда в нём?

Смысл - анализировать более-менее оконченную работу, например перед коммитом или во время PR. А если я нахожусь в процессе работы, мне что, этот кодоанализатор на каждый save исходников запускать? А иначе потом, когда кодоанализатор всё таки запустится, снова кодить всё что забыл и проверять не отвалилось ли чего?

А аннотация через аннотацию в аннотации добавляет читабельности? Или если ты не видишь проблему, то её нет?

Этих аннотаций на порядки меньше бойлерплейта.

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

В любой нормальной IDE есть кодогенераторы. Твой лобок - костыль и не более того, ты как и 95% остальных разрабов не понимают, что код больше читают, чем пишут. А любые неофициальные фичи лишь усложняют понимание кода.

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

А если я нахожусь в процессе работы

Если ты находишься в процессе работы, то твоя IDE тебе напомнит добавить геттер, проинициализировать поле в конструкторе или обновить hashCode/equals. Причём в последнем, я бы авто генерации не доверял, слишком большой риск. А статический анализ поможет не пропустить это в код ревью.

Этих аннотаций на порядки меньше бойлерплейта.

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

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

Ну ладно тебе, между 8 и 10 разница была некислая. А вот 10+ уже минорщина

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

Этих аннотаций на порядки меньше бойлерплейта.

Зато дебажить их просто божественно. Веселее только аспекты, для этих вообще отдельный круг ада есть

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

Зато дебажить их просто божественно. Веселее только аспекты, для этих вообще отдельный круг ада есть

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

Ждем records в 17ой java и выкидываем ломВбок на помойку истории.

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

Месье Дон Кихот? Воюете с ветряными мельницами бойлерплейтом? Да ещё и при помощи костылей? Тогда верно, не по пути.

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

Не зря же появились Records в Java и Immutables от Гугла. Но сейчас ИМХО многие вещи Ломбока не нужны или заменяются функционалов сторонних библиотек (тот же Immutables).

P.S.: сам насмотрелся на людей, которые вешают @Data на entity и не видят здесь ошибки.

Хочешь бойлерплейта и плюшек - пиши на Kotlin, но я бы не тащил Lombok в проект, т. к. человек уже пишет не на Java, а на отдельном языке Lombok Java.

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

Да я не спорю, что в яве полно бойлерплейта. Я лишь против костылей, которые типа «решают» проблему, а на деле добавляя ещё больше головной боли. Просто подход ломбока был изначально плохой. А вот Бреслав со своим котлином избрал правильный путь.

Immutables от Гугла

У них вышло лучше, чем в ломбоке. Но тоже есть ньюансы.

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

тебя просто перебросят в нужный кусок кода

Это блин не «просто перебросить», это программный гоп-стоп какой-то. Идёшь по коду никого не трогаешь хочешь в лог написать, тут вылетает из-за угла эта шайтан-приблуда и вместо записи в лог начинает слать метрики в prometheus.

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

Того, кто придумал шпринг на кол!

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