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 ()
Последнее исправление: cocucka (всего исправлений: 2)

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

Если ты находишься в процессе работы, то твоя IDE тебе напомнит добавить геттер, проинициализировать поле в конструкторе или обновить hashCode/equals.

Не напомнит, потому что у приватных полей вовсе не обязательно должны быть гетеры/сетеры, нефинальные поля не обязаны быть явно проинициализированы в конструкторе и так далее. Кроме того, анализатор кода в том же IntelliJ (официально купленном Ultimate), который работает в процессе написания/редактирования кода очень сильно обрезан, по сравнению с Inspect Code, который нужно запускать вручную и работа которого может занять немало времени.

А статический анализ поможет не пропустить это в код ревью.

Только если кто-то намеренно отключил поддержку Lombok.

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

Никогда не видел никаких кастомных аннотаций с комбинацией ломбочных. Обычно хватает стандартных аннотаций из коробки. Кастомные аннотации - это больше во время использования каких-то фреймворков, типа Spring. Но даже там это случается не часто. Согласен лишь в одном, что декларативное программирование при помощи аннотаций - не есть хорошо. Однако типичному использованию Lombok-а до таких извратов ещё далеко.

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

Зато дебажить их просто божественно.

Зачем дебажить сгенерированный код? Дебажить нужно лишь его использование.

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

А в чём проблема? Системным библиотекам ок иметь внутри switch-case по версиям ОС/JVM, такое бывает. При использовании JNI вообще приходится таскать версию библиотеки под каждую ОС и процессор.

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

Зачем дебажить тривиальные геттеры и сеттеры? Lombok ничего, что нормальный человек захочет дебажить, не генерирует.

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

Тому, кто придумал ломбок надо в голову гвоздь забить.

Гвозди в голову надо забить тем чудакам на букву м из команды жава, кто усиленно прячет нужные ломбоку потроха, в т.ч. классы AST. Пофиг на val/var и прочие мелочи что в жаву уже приехали; ломбок нужен чтобы собственные макросы писать.

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

А для чего ещё lombok нужен как не бойлерплейт убирать?

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

ломбок нужен чтобы собственные макросы писать.

Сишные макросы - это страх и ужас и в Java от них изначально решено было отказаться, оставив лишь рудимент в виде final static полей литералов, которые копируются в новые литералы, там, где используются, во время компиляции. Ломбок - это банальное декларативное программирование, которое обычно короче итеративного. Причем если в таких фреймворках, как Spring Boot декларативное программирование приносит много «магии», в Lombok всё достаточно просто и понятно, то есть никакой магии там нет.

hummer
()

Sealed Classes

Мало им приватных методов, так теперь рукожопие в библиотеках и через наследование будет не обойти - да здравствует решфлекшн.

ya-betmen ★★★★★
()

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

Тоесть жава стала ещё тормознее?

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

Это называется полиморфизм. Юзверю не кажется, что если разработчик сделал класс final или метод приватным – так и должно быть, а юзверь пытается микроскопом забить гвоздь?

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

Инкапсуляция* конечно же. Ночь на дворе, простите

anonymous
()

А почему запретили высказывать соболезнования по поводу смерти Линфана анонимусам? Знаю его ещё со времён SLORa (ресурс уже мертв). Довольно активный товарищ был.

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

Юзверь в данном случае такой же разработчик и закрывать от него возможность модификации это жлобство.

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

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

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

Хорошо, Винни, ешь говно дальше. Не буду с тобой спорить. Тащи всякие костыли в проект в угоду читаемости.

Не напомнит

Мне напоминает. Попробуй следовать нормальным конвенциям, может и у тебя заработает.

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

Откуда вы лезете, а? Пишите на других языках, а то нагородят говна и костылей, а потом люди страдают.

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

Зачем дебажить тривиальные геттеры и сеттеры?

Это бывает нужно сделать когда используют AOP или Hibernate или что-то еще, что меняет состояние объекта indirectly, есть необходимость выяснить, что же произошло (или на оборот, не произошло).

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

Вы так говорите, как будто это плохо

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

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

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

Есть логика кода/библиотеки/фреймворка. Чтобы сохранить логику часть кишок скрывают в частности потому что эти кишки внутри могут требовать инварианты, не обеспечиваемые извне. Разработчик подумал вместо юзверя и закрыл доступ. Если юзверь считает себя умнее – пусть напишет лучше.

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

Говно и костыли получаются там, где вместо напрашивающихся естественным образом решений (то что можно сделать в buildtime – нужно делать в buildtime) недоумки вроде тебя сидят в жёстких границах «best practices» убогих, кривых и давным-давно устаревших технологий (рантаймовая кодогенерация, вовсю используемая например спрингом и хибером). И естественно «страдают» от непонимания принципа, сформулированного МакКоннелом как «писать не на языке, а с использованием языка».

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

Собственно, про идиотов, не желающих ничему учиться и вместо этого поливающих говном тех, кто знает-умеет больше и тем разрушает внутреннюю гармонию нарциссизма идиотов, когда-то было уже на ЛОРе. Свожу воедино несколько каментов, вот ссылка на последний:

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

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

Fixed.

Меньше всего мейнстриму программисты. Разраб уволился, а код поддердивать некому ибо сперва надо нанять другого.

Fixed.

Меньше всего нужны люди. Нет человека - нет проблемы.

Fixed. Слава роботам!

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

Чего? Сам придумал – сам ответил? Причём тут спринг? Какие устаревшие технологии? Ты там в порядке вообще?

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

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

А чому нельзя?

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

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

Ждал твоего ответа чтобы тебя заигнорить, но такое убожество даже как-то неудобно.

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

Жди теперь его ответа как собачка.

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

Вы тоже из этих, из голубых?

Зачем вы мне грубите … Я хоть и технарь, но очень интеллигентный человек и такого себе не позволяю …

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

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

Lombok для Java это как moc для Qt.

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

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

Хорошо, Винни, ешь говно дальше. Не буду с тобой спорить. Тащи всякие костыли в проект в угоду читаемости.

Слив засчитан.

Мне напоминает.

Да неужели? Приведи пример кода, который я могу попробовать в IntelliJ IDEA Ultimate, чтобы оно мне напомнило. Вот в таком классе оно мне, о неиспользовании поля floors в equals() и hashCode(), не напоминает.

package com.example;

public class House {
    private final String address;
    private final int floors;

    public House(String address, int floors) {
        this.address = address;
        this.floors = floors;
    }

    public String getAddress() {
        return address;
    }

    public int getFloors() {
        return floors;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        House house = (House) o;

        return address.equals(house.address);
    }

    @Override
    public int hashCode() {
        return address.hashCode();
    }
}

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

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

hummer
()

Ого, уже 16 версия!

Когда-то юзал по нужде, альтернативы не было. Но остался доволен: на С++ ушло бы в 10 раз больше времени.

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

со своим голубым приставай

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

Владимир 123

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

Если он положительно о нём отзывался и не мог внятно аргументировать его необходимость (бойлерплейт не аргумент)

Единственная причина использовать ломбок, это блин бойлерплейт в джаве, алё.
Дальше по треду ты ни назвал ни одной причины не использовать ломбок кроме чего-то вроде «джава и без него может работать».
Да это прям вселенская мудрость. Джава без ломбока может работать, внезапно. С бойлерплейтом.

Аннотации тебе не нравятся? А кому они вообще нравятся? Весь код на спринге с гибернейтом похож на какой-то фортран из аннотаций. Их тоже выкинуть и самому всё писать?
Ломбок ничем не хуже этих древних подходов насквозь из рефлекшинов и ансейво. Чем он хуже? Почему у меня должен быть хоть какой-то другой аргумент кроме бойлерплейта?

Может ты просто не осилил и самодуришь на ровном месте дидовскими каргокультами? Чёт мне именно так и кажется.

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