LINUX.ORG.RU

Релиз Java SE 14

 , ,


0

2

17 марта была выпущена Java SE 14.

Представлены следующие изменения:

  • На постоянной основе добавлены выражения для switch в виде case VALUE -> {}, которые выходят из условия по умолчанию и не требуют оператора break.
  • Текстовые блоки, ограничиваемые тройкой кавычек """ вышли на второй предварительный этап. Добавлены управляющие последовательности \, которая перед переводом строки не добавляет перевод строки в многострочном блоке, и \s, которая обозначает один пробел.
  • На предварительной основе представлено новое поведение instanceof, позволяющее в дальнейшем развить сравнение по шаблону.
  • На предварительной основе представлены записи с ключевым словом record. Записи автоматически получают методы equals, hashCode, toString, геттеры к членам записи и конструктор.
  • Улучшено описание ошибок NullPointerException.
  • Добавлен упаковщик jpackage для самодостаточных приложений.
  • Порты для Solaris и платформ на SPARC объявлены устаревшими и могут быть исключены в будущем.

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



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

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

Открыв такой тест с наскоку понять что там происходит не просто

если тест сложен для понимания только из-за того что json убрали в ресурсы, то возможно с этим тестом что-то не так

он нужен только чтоб убрать большие sql запросы из java в xml

погоди. что вообще текстовые sql-запросы делают в яве?

Надуманно, кажись даже Idea на лету может декомпилировать class файлы

умеет. Только маленькое обновление или чистка зависимостей может привести к невероятно интересным последствиям. Проблема ломбока в том, что ты по факту вообще не видишь явно что там произойдет. Даже с jaxb-генератором было проще, ты хотя бы результат видел без прыжков с декомпилятором, пусть и в generated. Плюс если хочется нетривиальную валидацию - упс, часть классов будет ломбоком, часть самописная, больше зоопарка богу зоопарка.

В плане у ломбока, аспектов, спринга и прочих модных слов есть одна общая проблема - огромное количество черной магии. Ты сможешь сходу рассказать как работает изнутри каждая аннотация ломбока? Или как происходит врезка аспектов? Или канонiчный пример - во что развернется чудесная SpringBootApplication?

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

Ломбок не нужен, аннотации не нужны, стримы не нужны, лямбды не нужны, спринг не нужен. Только java EE 6.

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

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

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

аннотации эта блин самая спорная тема всей явы. вроде и удобно, а вроде рантайм и хрен его знает где оно выстрелит.

ломбок просто нинужон

из всех нововведений последних 10 лет имхо самое приятное - Optional. Потому что никакие Nullable, подсветка в IDE и жабодоки с варнингами не заставят на секунду остановиться и включить мозг. Ну и var сойдет, но только в связке с new, иначе расстрел.

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

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

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

если тест сложен для понимания только из-за того что json убрали в ресурсы, то возможно с этим тестом что-то не так

Ну хорошо, для больших json уместно, но если JSON занимает например 15 строк, неужели это повод его вынести в ресурс при наличии мультистрок? На пограничные 15 строк можно натравить статический анализатор на CI, чтоб никто не нарушал этого правила.

погоди. что вообще текстовые sql-запросы делают в яве?

Для orm пишут в аннотациях ql, запросы маленькие, но какая разница? Запросы в яве! Сейчас часто используют ORM потому все уже позабывали как это было раньше с raw sql, куча sql была прямо в java и одним из вариантов было использовать что-то вроде ibatis.

Мультистроки появятся и можно будет все это в жабе оставить. Никакой разницы с sql в xml или отдельных файлах, только экономия времени.

В плане у ломбока, аспектов, спринга и прочих модных слов есть одна общая проблема - огромное количество черной магии. Ты сможешь сходу рассказать как работает изнутри каждая аннотация ломбока? Или как происходит врезка аспектов? Или канонiчный пример - во что развернется чудесная SpringBootApplication?

Преждевременное беспокойство, ну ок, однажды что-то случится и чо? Один день дебага, но каждый день экономия по 15 минут чтения кода. Чем меньше кода не относящегося к бизнес процессам, тем лучше.

Вот честно, я кучу времени трачу на анализ кода, активно пользуюсь букмарками в idea, потоу как одна чать связанна с другой частью, которая в другом файле, а вызвается из третьего файла, после каждого бага у меня по 5-10 букмарков и столько же брейкпоинтов. Чтоб было понятно я не один работаю, в команде с десятью другими девелоперами и баги берутся из пула багов, потому если и встречаешь свой код, то он уже обычно модифицирован кем-то другим. Потому по моим представлениям нужно меньше кода и статические анализаторы на CI. В идеале вообще может язык сменить, на тот где ненужны аннотации, xml и прочие файлы в ресурсах.

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

аннотации эта блин самая спорная тема всей явы. вроде и удобно, а вроде рантайм и хрен его знает где оно выстрелит.

До аннотаций парсили Javadoc в compile time (встречал в GWT и еще где-то). Конфиги в XML я бы не сказал что было хуже, но и лучше не было. А аннотация @Override? Было упущение языка приводящее к ошибкам и его исправили такой аннотацией не ломая обратную совместимость.

из всех нововведений последних 10 лет имхо самое приятное - Optional. Потому что никакие Nullable, подсветка в IDE и жабодоки с варнингами не заставят на секунду остановиться и включить мозг.

В Kotlin и C# теперь кодируют информацию о Nullablilty в типе, если после типа стоит ? (например String? text = ...) значит значение может принимать null и тогда компилятор требует проверку на null перед использованием. Вот бы дождаться в java.

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

Scala функциональный язык, вообще он был завялен как мультипарадигменный, только это привело к тому что разные люди писали на ней в разных парадигмах, а kotlin это только «улучшенная java», ООП с extension functions, немного функциональных фишек, null-safety и возможностей построения DSL (type safe builder, infix функции, перезагрузка операторов), теперь еще и coroutines.
Scala проекты испытывают трудности с масштабированием т.к. программистов мало и стоят они дороже, не потому что они лучше, а потому что их мало. Как бум на js стартапы, когда цена js разработчика подскакивала до небес. Kotlin банально понятнее людям с ООП бэкендом, плюс отличная поддержка IDE с первого дня.

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

В KDevelop это cmake, плюс отладка, плюс поддержка vcs, плюс снипеты всякие, плюс быстрая навигация по коду, плюс некоторая поддержка рефакторинга(правда в плюсах более менее нормально это может разве только CLion), ну и там по мелочи всякое.
Единственно что меня в KDevelop не устраивало, так это его стабильность. Особенно бесило когда затупливало автодополнение и он тупо терял базу символов.

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

Не знаю, я помню в 2012 было много энтузиазма вокруг Scala, я, будучи java-девелопером, даже ходил по собеседованиям в скалы конторы в 2013-2014 годах, они не могли найти scala разрабов. Однажды я в такую контору зашел еще раз в 2015 году, разговорился, попытался поспрашивать по scala, мне там ответили что у них уже нету scala. Когда у них была scala у них было 5 человек, а когда второй раз заходил уже было наверное человек 15. Рынок трудовых ресурсов определил выбор инструмента.

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

Почему же? Сложность кода определяется количеством строк кода и функциональной/логической связностью участков кода. В том и другом случае исходный код — качественный показатель объёма и функциональной/логической связности.

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

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

А с ядром linux проблем нет ни в KDevelop ни в QtCreator.

Как следствие - на java активно живет только IDEA, использование остальных обусловлено только инертностью пользователей, которые привыкли к родным тормозам.

Java IDE кроме IDEA - в жопе.

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

А Netbeans саму себя может.

И KDevelop и QtCreator могут распарсить код самих себя и код ядра Linux.

А вот может ли распарсить код Linux этот NetBeans, Eclipse CDT и CLion до того, как их убьёт OOM Killer – очень хороший вопрос.

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

Преждевременное беспокойство, ну ок, однажды что-то случится и чо? Один день дебага, но каждый день экономия по 15 минут чтения кода

очень зависит от софта. Любой банк тебе скажет что лучше ты потратишь 15 минут каждый день чем у тебя будет день дебага в случае остановки всей системы. Иногда даже час это много, и если факапа в рантайме можно избежать - так лучше и сделать.

Для orm пишут в аннотациях ql, запросы маленькие

для того чтоб не писать в аннотациях придумали тот же жук.

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

В Kotlin и C# теперь кодируют информацию о Nullablilty в типе, если после типа стоит ? (например String? text = …) значит значение может принимать null и тогда компилятор требует проверку на null перед использованием. Вот бы дождаться в java

explicit null одна из лучших частей котлина, имхо. Но уверен на 99% что в яве этого не будет. Придется ломать хренову уйму обратной совместимости, включая базовые интерфейсы коллекций. Оракл на это не пойдет.

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

А Netbeans может может распарсить код ядра Linux не удивившись от обилия линуксизмов?

Мне как-то пофигу что Netbeans может парсить Java. Idea делает это лучше в разы.
Мне от Netbeans в своё время необходим был CMake, С++ и Qt, которые как оказалось лучше обрабатывались в KDevelop.

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

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

аннотации эта блин самая спорная тема всей явы. вроде и удобно, а вроде рантайм и хрен его знает где оно выстрелит.

ломбок просто нинужон

У меня такие же ощущения возникли при взаимодействии с перечисленным, особенно со Spring. Слишком много тёмной магии через аннотации, которую хрен пойми, как дебажить и посмотреть во что это развернётся и какая логика там появится. Понимаю, что всё приходит с опытом, но Learning Curve из-за этого «волшебства» оставляет желать лучшего.

Вот такой вопрос. Если бы сейчас тебе предложили написать не слишком сложный сайт с использованием Java, какой стек вместо Spring ты бы выбрал? Есть ли фреймворки, которые не вызывают твоего эстетического отторжения?

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

explicit null одна из лучших частей котлина, имхо. Но уверен на 99% что в яве этого не будет.

Мне всё же кажется, что проблема NPE слишком преувеличена. Неужели Java-разработчики так часто сталкивались с этими исключениями, что решение этой проблемы в Kotlin стало для них глотком чистого воздуха?

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

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

Другое дело что анализатор в какой-то момент они сломали и я вообще ушёл на VS Code.

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

Понимаешь, npe это прям чемпион на титул «идиотская ошибка года». При том это еще и unchecked, что вообще странно для явы.

Стандартный вариант - ты долго и нудно пишешь клиент к стороннему сервису, с помпой его выкатываешь, а потом с воплями «срочно в номер» катишь хотфикс потому что в спеке забыли указать что в каком-то из списков могут быть null. Глупо и обидно.

Это как по минному полю ходить - вроде пока живой, но хз где и когда рванёт

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

Если бы сейчас тебе предложили написать не слишком сложный сайт с использованием Java, какой стек вместо Spring ты бы выбрал?

Да шпринг бы и взял :( ну в плане не на сокетах же писать. Смотря что за сайт. Если совсем мелочь на 3.5 ручки - можно какой-нибудь Blade и скрестить с даггером чтоб autowiring. Шпринг в базе вполне неплох, главное не лезть во всякие integration

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

Так и про кобол можно сказать. А знаешь сколько всего на нем живет

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

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

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

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

За пределами банков и корпораций, в публичных сервисах и стартапах скорее всего жаба не так популярна.

потому стартапы и проваливаются, дохнут один за другим

Karapuz ★★★★★ ()