Comments 64
Свифту 4 всего 2 года, а 5 лет назад в него внедрили, ага.
Ява, конечно, в догоняющих, но догоняет точно не эпл :).
На Java по-прежнему работают программы, написанные чуть ни не в самых первых версиях, именно благодаря такому подходу.
Любая фича в языке интерферирует вообще со всеми другими фичами в языке, причём не только уже существующими, но и теми, что вы захотите добавить потом. Посмотрите на C++. Начиная с определённого порога заканчиваются понятные ключевые слова и синтаксис, и приходится начинать использовать непонятные. Или, как Вы выразились — отсекаем лишнее, и ломаем все программы, потому что до версии
X
оператор <:~:
означал выход из корутины, а на момент выхода версии X + 1
корутины перестали быть модными, их сочли лишними и выкинули из языка, зато теперь оператор <:~:
освободился, и его приспособили для атомарной записи в файл — разумеется, с ошибкой компиляции если типы не подошли.Я бы посмотрел на Вашего босса, когда Вы ему сообщите, что ETA перехода на версию
X + 1
(где присутствует критическая для него заплатка CVE) составляет год, потому что старый код теперь нужно отсечь, а новый писать заново.> Тот же Internet Explorer взять.
Этот опыт на самом деле нас учит не тому, что надо брать всё самое современное, а тому, что типичная для Microsoft тактика EEE иногда даёт слабину, и тогда они сокрушительно теряют позиции. Но и при этом в некоторых организациях до сих пор крутится и жрать не просит какая-нибудь внутренняя система, работающая только на IE, и организацию это полностью устраивает.
Да, поэтому Java такая медленная в плане внедрения всего самого нового, потому что энетерпрайз такой.
В Груви 15, но кто считает.
Вот надо написать тест, который проверяет, что объект правильно сериализуется в Json. Тогда делаешь текстовый файл, в котором отформатированный json, а потом сравниваешь его содержимое с результатом сериализации. И очень удобно было бы видеть этот отформатированный json прямо в коде теста. Но это в 12 джаве невозможно.
String html = """
<html>
<body>
<p>Hello, world</p>
</body>
</html>
""";
Весь смысл record Foo {}
не в уменьшении boilerplate, а именно в том, что он урезанный. У него не должно быть собственного identity, чтобы не таскать за собой "лишних" данных, заголовков, wait-списков и прочей чепухи, которой никто не пользуется, и иметь возможность инлайнить такие объекты в массив не перемежая их теми самыми заголовками. Именно поэтому они немутабельные — так как нету заголовка, всё состояние описывается значением полей, следовательно "другое значение поля <==> другая запись".
Но работа над этим ведётся так долго именно от того, что все в округе хотят всего и сразу. Насколько я помню, в недавних докладах уже рассказывали, что из-за public demand пришлось чуть ли не повернуться на 180, и какие-то вещи оставить. Но вот точно могу сказать, что чем больше у вас запросов вида "хочу не урезанных" — тем меньше у вас причин пользоваться записями. Если вы хотите только синтаксис — берите Lombok (ну или Kotlin сразу, чего мелочиться), а та фича про оптимизацию памяти.
inline class Foo {}
или
record Foo {}
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
Кого-то мы там по пути потеряли вроде JEP 343: Packaging Toolа какие есть альтернативы, кто что использует для этого?
Например, rpm-maven-plugin для RHEL/CentOS
Надо полагать, для поддержки всего зоопарка нужно прикручивать и другие плагины. А тут вам на блюдечке будут предлагать готовое решение из коробки и на все случаи жизни. Жду не дождусь, когда добавят
Доки вполне понятны, если нужна помощь — обращайтесь.
del
И spring со своим блин перепакованным spring asm'ом…
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 57
at org.springframework.asm.ClassReader.(ClassReader.java:184)
Возможно, кто-то (lany, ау!) сможет продолжить эту работу
Вон Саймон уже написал.
Ну на самом деле, ничего особо интересного далее содержимого этой статьи он не написал. Все то же перечисление джепов, а я имел в виду про то, что нужно пройтись не по джепам, а по багам. Взять все баги, в которых были изменения за полгода, пройти последовательно и выписать самое интересное. Я не чувствую, что у меня будет время и силы на такую работу
Ну свежие апишечки он в конце перечислил, а это не часть джепов. Просто прямо скажем ничего нового в этой вашей джаве 13 не появилось :-)
Не разбор багов, конечно, но всё же кое-что накопал про JEP-350 Dynamic CDS Archives применительно к Spring Boot: https://m.habr.com/ru/post/472638/
Многострочные строковые литералы до сих пор не внесли в список особо зловонных Code Smells?
Очень странно.
А String.formatted()
вошёл в тринадцатку? Он был частью jep-а про многострочные стринги но сходу о нём информации не нашлось
В реальной работе они минимум через год, а то и два появятся — а к тому моменту уже не будут поддерживаться.
Остается LTS 11.
Если что-то поддерживает 8 — с этим уже можно удобно работать, если 9 и упаковано в модуль — тем более хорошо. А вот всё остальное это сугубо некритично, в пользовательском коде откликается чем-то вроде мелких улучшений.
И в официальных заявлениях о поддержке всё очень логично. 11-я версия носит метку LTS — её все и будут официально поддерживать, и это правильно. Когда выйдет следующий LTS-релиз — будут официально поддерживать его. Это вовсе не означает, что промежуточные версии никто не поддерживает, это нужно делать хотя бы потому, что иначе прыжки через несколько релизов будут очень тяжелыми.
Что значит "не поддерживает", какие ваши доказательства?
docs.spring.io/spring-boot/docs/current/reference/html/getting-started-system-requirements.html
Хотя там контрастным по менее контрастному написано, что
up to 12 (Included)Так что непонятно, откуда дровишки.
Вот ContainerTools действительно никто, вроде, не собрал для JDK 12.
Java 10 is supported as of Spring Boot 2.0.1.RELEASE. Java 11 is supported as of Spring Boot 2.1.0.M2. The plan is to officially support Java 12 as of Spring Boot 2.2
github.com/spring-projects/spring-boot/wiki/Spring-Boot-with-Java-9-and-above
Java взяла курс на моду и молодёжность, чтобы не выглядеть совсем уж замшело в глазах нынешних программистов, у которых новый любимый фреймворк рождается, делает несколько мажорных релизов без обратной совместимости, и умирает — за время, пока Java всё ещё готовит к релизу очередную версию с кучей плюшек.
Логически не-LTS релизы JDK теперь, видимо, имеют смысл минорных версий — насколько я помню, они даже
@Deprecated(forRemove)
будут удалять именно в LTS релизах. Плюс Preview Features, да плюс инкубаторы — разумеется, этот зоопарк не для кровавого интерпрайза, а для экспериментов и смузи.Ну да, на острие придётся быть «на свой страх и риск». А где-то и когда-то это разве было не так?
На нашем родном проекте будут вводить JDK 12/13 из-за внутренних изменений, но вот language target на всём проекте до сих пор 8 (да, кровавый интерпрайз), хотя я бы лично был бы очень рад текстовым блокам, например.
Официально будет в Boot 2.2, а он ещё не вышел.
Только что вышла Java 13. ZGC начал делиться памятью, CDS сам запоминает классы, и другие чудеса техники