JUG Ru Group corporate blog
Programming
Java
Compilers
Comments 64
-22
Apple внедрила text blocks в Swift 4 уже лет 5 как. Сколько помню, Java всегда в роли догоняющих
+14

Свифту 4 всего 2 года, а 5 лет назад в него внедрили, ага.
Ява, конечно, в догоняющих, но догоняет точно не эпл :).

+2
Это как когда Swift всего год как вышел, а уже были вакансии с требованием опыта на Swift от 5 лет)
0
Вот здесь не стоит обобщать. У меня учеба вошла в стаж, и в 20 лет в моей трудовой можно было насчитать примерно 5 лет стажа. Если бы учился на заочке, то как раз к 21 получилась бы и вышка в придачу
0
Опыт != стаж. Да, я ошибся, нужно было написать опыт работы. На стаж всем плевать, кроме пенсионного фонда.
-3
2 года это конечно не 5 лет, но и не конец 2019. Java и правда где-то в ж%пе и уже лет N как. Да и Apple как-то потехнологичнее будет Oracle
+2
Можно на это смотреть как на «следование в ж%пе». Но с другой стороны — язык, как и полагается старику с огромным количеством легаси, позволяет юношам с горящими взорами (которым нечего терять) кидаться на минное поле первыми. А потом собирает самые удачные остатки.

На Java по-прежнему работают программы, написанные чуть ни не в самых первых версиях, именно благодаря такому подходу.
-1
Очень сомнительное преимущество — поддержка старого кода. Опыт IT показывает, что если тянуть лямку слишком долго, то итог плачевный. Тот же Internet Explorer взять. Поэтому либо ты идёшь вперёд, беря с собой самые современные наработки и отсекая старьё, либо ждёт забвение на свалке истории
+2
Вот и Java идёт вперёд — по дорожке, расчищенной более молодыми языками. И при этом имеет возможность тщательно выбрать, какие из модных веяний стоит включить в язык и стандартную библиотеку, а какие — всего лишь веяние, и завтра мода уйдёт, а фича языка останется, и её придётся поддерживать.

Любая фича в языке интерферирует вообще со всеми другими фичами в языке, причём не только уже существующими, но и теми, что вы захотите добавить потом. Посмотрите на C++. Начиная с определённого порога заканчиваются понятные ключевые слова и синтаксис, и приходится начинать использовать непонятные. Или, как Вы выразились — отсекаем лишнее, и ломаем все программы, потому что до версии X оператор <:~: означал выход из корутины, а на момент выхода версии X + 1 корутины перестали быть модными, их сочли лишними и выкинули из языка, зато теперь оператор <:~: освободился, и его приспособили для атомарной записи в файл — разумеется, с ошибкой компиляции если типы не подошли.

Я бы посмотрел на Вашего босса, когда Вы ему сообщите, что ETA перехода на версию X + 1 (где присутствует критическая для него заплатка CVE) составляет год, потому что старый код теперь нужно отсечь, а новый писать заново.

> Тот же Internet Explorer взять.

Этот опыт на самом деле нас учит не тому, что надо брать всё самое современное, а тому, что типичная для Microsoft тактика EEE иногда даёт слабину, и тогда они сокрушительно теряют позиции. Но и при этом в некоторых организациях до сих пор крутится и жрать не просит какая-нибудь внутренняя система, работающая только на IE, и организацию это полностью устраивает.
+1
Ваши предложения, что нужно делать банкам сейчас? Отказаться от текущего бизнеса, закрыться и открыться заново с чистого листа на новом языке? Или же вы предлагаете переписать софт на новый язык, который писался лет 20-30? Кто оплати эти издержки? Да, когда открывается новая компания, то есть смысл брать всё новое и желательно стабильное. Когда стартап перерастает себя и становится бизнесом среднего звена, то ему не помешают наработки за прошлые года. А когда это происходит, то ему вообще не важен новый фреймворк, главное — функционал, на который ушло время и деньги. Бизнес не зарабатывает на том, что для них пишут новый софт. Софт — это сопутствующий инструмент для бизнеса. Не все же крутиться на ММО-гриндилках, когда проект себя иссяк и можно смело закрыть сервак и открывать новый, с новой игрой, на новом движке и софте.
Да, поэтому Java такая медленная в плане внедрения всего самого нового, потому что энетерпрайз такой.
+6
А вы кроме Apple не знаете никого? В Scala и Groovy это есть лет 10.
+4
Эти блоки являют собой некую киллер фичу? Пол-года пишу на Котлине, где это тоже есть, но какого-то кайфа от появления такого инструмента в своей повседневной работе не испытал. Просто чуть удобнее.
+7
Тут скорее не кайф от того, что это есть. А боль от того, что этого нет.
-1

Вот надо написать тест, который проверяет, что объект правильно сериализуется в Json. Тогда делаешь текстовый файл, в котором отформатированный json, а потом сравниваешь его содержимое с результатом сериализации. И очень удобно было бы видеть этот отформатированный json прямо в коде теста. Но это в 12 джаве невозможно.

+3
Положите Json в отдельный файл, не мучайте программистов такими вставками в код
+1

Сейчас я так и делаю, но мне кажется, что открывать отдельный файл ради того, чтобы посмотреть на 5 строк json, которые в нём находятся, гораздо мучительнее, чем посмотреть на текст, который находится в том же самом файле, что и тест.

+10
Легко внедрить что-то в молодой и модный язык. А когда у тебя лежит на сердце тяжкий груз legacy каждую новую фичу добавляют с большой оглядкой.
+1

Так, а разве у разработчиков Свифта на сердце лежит хоть какой-то тяжести груз легаси? На сколько знаю они не особо к обратной совместимости, просто ломают все при переходе на новую версию и не парятся.

+2
Основной потребитель Java — это корпоративный сектор, а они перемен не любят, в энтерпрайзе до сих пор работает огромное количество кода, написанного в 70-х.
+4
Первый пример из JEP 355 перепутан: это как раз как есть сейчас — «one dimensional». А должно быть «two dimensional»
String html = """
              <html>
                  <body>
                      <p>Hello, world</p>
                  </body>
              </html>
              """;
0

Поправил. Сорри, очень непросто на ходу набирать текст на планшете

+1

Жаль счастливый номер релиза пропустил такую счастливую пятницу...

-2
Хотелосься чтобы в Java добавили. Но можно использовать Lombok.
0
Читал, что хотят уменьшить boilreplate код с помощю record, а как с остальными классами. И record которые-то хотят завести, какие-то урезанные. Хотят только readonly. Хотелось, чтобы было как в Kotlin: мутабельные и немутабельные.
+1

Весь смысл record Foo {} не в уменьшении boilerplate, а именно в том, что он урезанный. У него не должно быть собственного identity, чтобы не таскать за собой "лишних" данных, заголовков, wait-списков и прочей чепухи, которой никто не пользуется, и иметь возможность инлайнить такие объекты в массив не перемежая их теми самыми заголовками. Именно поэтому они немутабельные — так как нету заголовка, всё состояние описывается значением полей, следовательно "другое значение поля <==> другая запись".


Но работа над этим ведётся так долго именно от того, что все в округе хотят всего и сразу. Насколько я помню, в недавних докладах уже рассказывали, что из-за public demand пришлось чуть ли не повернуться на 180, и какие-то вещи оставить. Но вот точно могу сказать, что чем больше у вас запросов вида "хочу не урезанных" — тем меньше у вас причин пользоваться записями. Если вы хотите только синтаксис — берите Lombok (ну или Kotlin сразу, чего мелочиться), а та фича про оптимизацию памяти.

0
Признаюсь, я думал, что речь в целом шла про inline class, а record — это прежнее название того же самого, но в прошлом.
Сейчас перепроверил, и таки нашёл их parent JEP 359 (про который просто преступно мало информации — видимо, все сейчас смотрят на Вальгаллу).
Тем не менее, штука про отсутствие собственного identity (точнее, логическому равенству между state и identity) и «другие значения <==> другая запись» тут ещё более применимы, это проистекает из самого исходного требования о полном соответствии состояния объекта его identity. Словами автора (в весьма вольном переводе):
Аргумент против изменяемости записей более сложен [чем против расширяемости], так как, в теории, вполне можно представить примеры когда возможность мутировать не идёт против основной цели создания подобных типов. Однако, изменяемость мешает соответствию между состоянием объекта и API его типа. Например, как правило, будет ошибкой использовать изменяемое состояние в методах equals() и hashCode(), так как это создаёт возможность для подобных элементов, к примеру, «неожиданно исчезать» из HashSet'ов или словарей HashMap. Иными словами, изменяемые поля записей означают, что мы хотим использовать протокол equals/hashCode, отличный от определения состояния; либо же, мы хотим конструировать подобные объекты по-другому (объекты во многих доменах создаются с использованием конструктора по умолчанию, а затем «заполняются» состоянием посредством вызова сеттеров, либо их конструктор принимает только поля их «натурального ключа».) Такие объекты, теряют одно из основных важных отличительных свойств: мы более не сможем выделить их API только лишь из описания их состояния. (И, как только мы введём в рассмотрение изменяемость, нам придётся также думать о потоко-безопасности, а это будет сложно примирить с основными целями введения записей в язык.)

cr.openjdk.java.net/~briangoetz/amber/datum.html, секция Restrictions/Mutability
+2
По пятницам по прежнему нельзя, а в остальные дни — пожалуйста
+1
В продакшине будет использоваться LTS версии. Следующая Java 17, и то после пару лет после выхода и исправления ошибок.
0
Кого-то мы там по пути потеряли вроде JEP 343: Packaging Tool
а какие есть альтернативы, кто что использует для этого?
0

Например, rpm-maven-plugin для RHEL/CentOS
Надо полагать, для поддержки всего зоопарка нужно прикручивать и другие плагины. А тут вам на блюдечке будут предлагать готовое решение из коробки и на все случаи жизни. Жду не дождусь, когда добавят

0
Им уже можно спокойно пользоваться. Я пробовал делать msi для Windows и pkg/dmg для Мака — всё отлично работает. Да, есть некие опасение, что это всё ещё early access, но кто мешает попробовать и потестировать?
Доки вполне понятны, если нужна помощь — обращайтесь.
0
А liberica тормозит со сборкой… У них только ea…
И spring со своим блин перепакованным spring asm'ом…

Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 57
at org.springframework.asm.ClassReader.(ClassReader.java:184)
+1

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

+1

Ну свежие апишечки он в конце перечислил, а это не часть джепов. Просто прямо скажем ничего нового в этой вашей джаве 13 не появилось :-)

0

Многострочные строковые литералы до сих пор не внесли в список особо зловонных Code Smells?
Очень странно.

0

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

0
А можно попросить пример? То ли у меня кейсов таких нет, то ли мимо меня прошел удобный трюк…
0

А String.formatted() вошёл в тринадцатку? Он был частью jep-а про многострочные стринги но сходу о нём информации не нашлось

+1
Смешно — Spring Boot еще 12 не поддерживает, Google Jib поддерживает 8 и 11, а тут уже 13.

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

Остается LTS 11.
0
Так ведь и не появилось, по сути, ничего такого ни в 12-й версии, ни в 13-й, что требовалось бы специально поддерживать. Ну что там, улучшенный ZGC? CDS-архивы? Как библиотека сможет это поддержать, а главное — зачем? Опять же, поддерживать preview-фичи — себе дороже, всё равно придётся что-то переделывать в итоге.
Если что-то поддерживает 8 — с этим уже можно удобно работать, если 9 и упаковано в модуль — тем более хорошо. А вот всё остальное это сугубо некритично, в пользовательском коде откликается чем-то вроде мелких улучшений.
И в официальных заявлениях о поддержке всё очень логично. 11-я версия носит метку LTS — её все и будут официально поддерживать, и это правильно. Когда выйдет следующий LTS-релиз — будут официально поддерживать его. Это вовсе не означает, что промежуточные версии никто не поддерживает, это нужно делать хотя бы потому, что иначе прыжки через несколько релизов будут очень тяжелыми.
0
А. Если нужна прямо официальная поддержка, то пока придётся пользоваться LTS. Даже у самой 13-й версии окно официальной поддержки от разработчиков(!) длится ровно до выхода JDK 14, в отличие от 11, у которой поддержка будет вроде даже немного после выхода JDK 17. Но обратную совместимость между 11, 12 и 13 вроде не ломали, так что разрабатывать вполне можно уже сейчас, а тем временем подтянется и соответствующий релиз Boot.

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

Логически не-LTS релизы JDK теперь, видимо, имеют смысл минорных версий — насколько я помню, они даже @Deprecated(forRemove) будут удалять именно в LTS релизах. Плюс Preview Features, да плюс инкубаторы — разумеется, этот зоопарк не для кровавого интерпрайза, а для экспериментов и смузи.

Ну да, на острие придётся быть «на свой страх и риск». А где-то и когда-то это разве было не так?

На нашем родном проекте будут вводить JDK 12/13 из-за внутренних изменений, но вот language target на всём проекте до сих пор 8 (да, кровавый интерпрайз), хотя я бы лично был бы очень рад текстовым блокам, например.
Only those users with full accounts are able to leave comments. , please.