Valhalla в Java

Не слышал, чтобы оно было доступно. По-моему они пока обдумывают эту фичу. Актуальная информация тут (openjdk.org). С нынешней скоростью развития жавы релиз я бы ждал лет через 20. У нас походу опять эпоха Java 7, где ничего нового не происходит уже много лет.

Многие ещё на 11-й сидят, а то и вообще на 8-й, хотя на дворе вышла 23-я в прошлом году. Так что ты требуешь гиперзвуковых скоростей по введению новых фич. ¯\_(ツ)_/¯

Заставлять кого-то переходить на новые версии я не собираюсь, но когда в очередном релизе я вижу ровно 0 новых стабильных фич (и с десяток экспериментальных, которые я даже не читаю), это слегка грустно - типа а зачем вообще новую версию было выпускать?

В этом году зарелизить собираются только JEP 450: Compact Object Headers. А Valhalla это долгострой который не известно когда будет. В прошлом году была выпущена какая-то сборка для желающих посмотреть, https://jdk.java.net/valhalla/.

Единственный способ использовать Valhalla сейчас - это смотреть видосики с конференций.

(Ну или быть одним из разработчиков jvm)

Потому что кроме запила новых фитч можно допиливать старые. Например, более быстрая сборка мусора или какие-то ещё замечательные оптимизации.

Оптимизации это не фичи и не требуют выпуска нового релиза языка. Ну за каким-то исключением.

Как я понимаю, к версии ЖВМ привязана версия языка. Ну т.е. можно сильно поменять жвм и изменения тянут на новую версию, а сам язык при этом не поменялся. Но версию крутят.

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

По твоей ссылке можно без труда добраться до инструкции: https://github.com/openjdk/valhalla/blob/lworld/doc/building.md

типа а зачем вообще новую версию было выпускать?

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

… но когда в очередном релизе я вижу ровно 0 новых стабильных фич (и с десяток экспериментальных, которые я даже не читаю), это слегка грустно - типа а зачем вообще новую версию было выпускать?

Скорее всего, платные услуги технической поддержки Джавы покрывают лишь одну купленную версию. Меняем номер версии Джавы -> принуждаем платных пользователей платить снова и снова.

А можно лучше как-нибудь сделать named params + default param values? Единственное, чего мне нынче прям сильно не хватает по сравнению со скалой. Недавно нагуглил обсуждение разрабов jvm – IDE-шники и прочие долбят их за эту фичу уже давно, но это оказывается не такая простая фигня как мне казалось: надо формат .class-файлов подкручивать (что понятно: оттранслированный вызов – с позиционными параметрами, но при загрузке класс-файла сопоставление будет по именам, а порядок параметров в загружаемой версии .class-файла заранее неизвестен и может отличаться от того, который был у разработчика вызывающего кода).

Что никаких новых фичей – это vbr конечно загнул. За один только паттерн-матчинг можно пару подносов с пирожками им на полку подогнать. Жареными, с тонким тестом и вкусной пюрешкой с редкими вкраплениями жареного лука в качестве начинки. Лёгкие потоки – не пробовал, хотя по докам выглядит весьма толковой фичёй. Из мелочей нравиццо например _.

Что там ещё было большое – помню выборочно. Математика-матрицы – бред собачий и эталонное ненужно, records – полнейшее убожество рядом со скаловскими case-классами (но если бы были именованные аргументы и соответственно дефолтные значения…).

А про сабж – смешно, конечно. Потому что в .NET CLR оно было изначально.

Не разделяю восторга. Паттерн-матчинг это супер-крохотный синтаксический сахар над if. Я может пропустил, но по-моему даже их хвалёные рекорды нельзя разбирать паттерн-матчингом? Это вообще не паттерн-матчинг по сути. Да даже если бы и был - смысл в нём в очень небольшом количестве кода. Редко пригождается вся его мощь.

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

Ну рекорды будут второй фичей. Когда их допилят, ага. Пока они так же неюзабельны на пределами тривиальных случаев вроде Point2D. А там, где юзабельны, вызывает много вопросов - нафига? Написать аналогичный класс - несложно, преимуществ 0, недостатков хватает. Вроде обещали и декомпозицию и многое другое, ну обещанного, видимо, тридцать три года ждут.

Математика-матрицы – бред собачий и эталонное ненужно

Это для финтех контор, которые используют блокчейн (биржи), нейронок и прочего.

То что вы с этим не сталкивались в своей работе не значит что это ненужно. Это фичи для одних из самых платежеспособных клиентов использующих java.

Паттерн-матчинг это супер-крохотный синтаксический сахар над if.

Ну так-то да, но совсем без него частенько бывало тоскливо. А сам я не верил, что они осилят сделать нормально, не изгадив синтаксис – потому и порадовался: надо же, осилили.

Редко пригождается вся его мощь.

Внешний полиморфизм – достаточно частый кейс.

Написать аналогичный класс - несложно

А с помощью одной-двух lombok-аннотаций – не сложнее чем сам record, ещё и фичастей выйдет, и гибче. Я собственно и написал, что record – хрень на палочке.

Я собственно и написал, что record – хрень на палочке.

Я, собственно, жду т.н. wither-ов:

var point2 = point1 with { y = y + 1 }

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

var point = new Point with { x = 1; y = 2; }

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

Заодно можно и именованные аргументы со значениями по умолчанию имитировать:

foo(FooParams.DEFAULT with { paramX = 123; });

Страшно, конечно, но жить можно.

Я имел в виду, что на моё имхо тяжёлые вычисления надо делать ТОЛЬКО на сях/плюсях. Потому что даже если жаверы заморочились оптимизацией отдельных операций, хоть сколько-нибудь сложный алгоритм целиком против unsafe-нативщины никакой managed не вывезет.

Для меня в свое время было открытием что Java, внезапно, может быть прям очень быстрой, если её уметь готовить.

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

Заодно можно и именованные аргументы со значениями по умолчанию имитировать:

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

В плюсах мне тоже named params не хватает, я там частенько param objects юзаю ради designated initialization. И меня дико бесит, что например 16-байтная структура ВСЕГДА протаскивается через стек вместо того чтобы через 2 регистра. Если бы не это, то и хрен бы с ними, я плюсы не ради удобства говнокодинга выбрал.

Разве только если все данные запихать в byte[] и работать с ним вообще не используя идиоматическую жаву. Может когда эта valhalla появится – будет попроще. А пока что – звиняйте.

А ты из каких соображений эту фигню ждешь?

Разве только если все данные запихать в byte[]

Чего там только нет, protobuf это лишь вершина айсберга.

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

AI раньше тебя заменит чем Вальгалу до ума доведут.

Плодят сущности и синтаксические конструкции, опять по каким-то причинам не захотели сделать то что уже есть в других языка, а именно именные параметры методов point.copy(x=1, y=0)
А деструктуринг через паттерн матчинг?! Жесть. Там же еще этот ужасный instanceof добавляет нагромождения, неужели так тяжел добавить на последний алиас is.

Популярные фичи вроде пытаются подбирать, но язык становится каким-то ненормальным, на каждый специальный случай своя синтаксическая конструкция (анти LISP).
ИМХО Хорошо что string template выкинули, я понимаю что технически это шаг вперед, но как же он УЕБИЩНО."Выглядел \{да}" синтаксически.

Популярные фичи вроде пытаются подбирать, но язык становится каким-то ненормальным

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

Вот тут да, к примеру в Java уже сто лет все пишут дата-классы с геттерами-сеттерами. В C# есть спец-синтаксис. В котлине сделали спец-синтаксис. В скале сделали. В ломбоке сделали. Но в жаве просто взять и сделать то же самое, давно проверенное и широко используемое - нет, мы придумаем своё. Причём я пытался эту мысль донести до одного из разработчиков жавы, они как бы всё понимают, но считают, что весь мир идиоты, и мы им покажем, куда надо двигаться (в сторону насильственной иммутабельности).

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

А вот функциональщина без паттерн матчинга или попытка заменить отсутствие нуллсейф оператора опшеналом. Коллекции опять же стоило бы переписать если им так хотелось иммутабельность впилить.

Но в жаве просто взять и сделать то же самое, давно проверенное и широко используемое - нет, мы придумаем своё

к слову сказать, если до 7-й жавы были мысли, про то, что у платформы наблюдается определенный застой, то после 8 стало понятно, что у дидов просто-напросто отсутствует потенция: в какой угодно JEP ни плюнь, везде прослеживается какая-то недосказанность и этот бедный JEP маринуется десяток лет, если на примерах:

• сделали JEP 150: Date & Time API, в JDBC оно в итоге так и не попало толком, что вызывает кучу боли; парсить строковое представление дат все также приходится через одно место (кому-то взбрела в голову, что ISO 8601 - это наше все и никак иначе, а о том, что приложения обычно в гетерогенных средах работают - все плевать похоже), а после того как решили еще данные от IANA пихать, так постоянно начинаешь с лулзами сталкиваться: вчера сентябрь сокращался как Sep. а сегодня стал вдруг Septю
• Optional - какая-то невероятная отрыжка: в полях класов использовать толком нельзя, в методы передавать нельзя, цепочки вызовов по красоте строить тоже толком нельзя
• JEP 395: Records - это просто жесть, ну ладно, если нет потенции, посмотрите что уже есть в @lombok.Data, так вот нет, они еще умудряются этот самый Lombok каждый релиз ломать
• JEP 444: Virtual Threads - совершенно непонятно кому он вообще сдался, ну да, proxy-сервер на жаве толком не напишешь, но остальным-то он зачем?

proxy-сервер на жаве толком не напишешь

Чавой-то не напишешь? Асинхронный IO в Java появился ещё до того, как я программировать начал. Вообще без проблем напишешь.

Асинхронный IO в Java появился ещё до того, как я программировать начал. Вообще без проблем напишешь

то что что-то появилось, совершенно не означает, что оно работает, AsynchronousServerSocketChannel (скорее всего о нем речь идет), внутри хочет поток на каждое соединение, со всеми вытекающими, в целом мест, где эти виртуальные потоки действительно нужны можно пересчитать по пальцам одной руки опытного токаря, а как только доходит до необходимости работать с ресурсами, ограниченными по capacity (хз как правильно на русский перевести, но в БД 10 тысяч соединений никак не затолкать), то выясняется, что толку от этих виртуальных потоков нет никакого.

Ну да хрен с ним, проблема в том, что разработчики этого project loom как-то слабо врубаются в реальные потребности со стороны «пользователей» JVM, вот они посидели и решили, что ThreadLocal - отстой: нужно писать try/finally (на самом деле не проблема совсем), какой-то код может этот ThreadLocal внутри себя переписывать (тут уже проблема), и на свет родилось ScopedValue - вот теперь вопрос: а почему я не могу через ScopedValue посмотреть какие значения были до этого? т.е. оно выдает мне только последнее значение на стеке и все, а если я хочу какую-то «историю» видеть, то извини, друг, храни Deque в ScopedValue, что в действительности все их бредовые идеи делит на ноль.

AsynchronousServerSocketChannel (скорее всего о нем речь идет), внутри хочет поток на каждое соединение, со всеми вытекающими

Что ты имеешь в виду? Там же везде есть асинхронные методы с CompletitionHandler`ами, выпоняемыми на threadpool`е.

то что что-то появилось, совершенно не означает, что оно работает

Конечно оно работает.

AsynchronousServerSocketChannel (скорее всего о нем речь идет), внутри хочет поток на каждое соединение

Это уже в Java 7. Исходно там был SelectableChannel и тд. Там код пишется ровно так же, как на C с select-ом. А с Java 7 новинками всё стало совсем просто.

толку от этих виртуальных потоков нет никакого.

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

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

Для большинства типовых сервисов это всё не надо, тут не спорю. Им вообще технологий 90-х хватает за глаза.

1. Проблемы ждбц, дефолты да, странные, да ещё и запиханы в неочевидные места

2. Как замена нуллсейф более менее, а как монада - говно

3. Да норм рекорды

4. Тебе не нужны ты мимо проходи, хотя со стороны выглядит жутковато

2. Как замена нуллсейф более менее

Яп поспорил: (1) optional-поле тоже может быть surprise null (surprise!), так что защита весьма условная; (2) бедный GC.

3. Да норм рекорды

Эталонное убожество. Плюсую что lombok.Data удобнее, хотя по сравнению со скаловскими case-классами – тоже убожество, т.к. в самом языке нет ни named params, ни destructuring (unapply).

optional-поле

Какой идиот будет делать опшенал поле? Опшенал не для этого же.

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

String value = a?getB()?getC()?getValue();

А опшенал это нуллсейф курильщика. Но это всё равно лучше т.к. раньше вообще никакого не было.

Естественно ofNullable метода там быть не должно а of должен работать как ofNullable, но это уже другой вопрос.

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

String value = a?getB()?getC()?getValue();

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

Естественно ofNullable метода там быть не должно а of должен работать как ofNullable, но это уже другой вопрос.

вероятно проблема в том, что of - так себе название для статического метода: в случае import static оно будет вызывать массу проблем, а вот ofNullable уже можно как-то связать с Optional

Опшенал не для этого же

Вот тут (https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555) Гойц пишет как предполагалось использовать Optional, фактически это исключительно некий контракт на возвращаемое методом значение, мол раз вернули Optional, то это точно не null (нигде не форсируется при этом) и это нужно бы обработать - такой Optional нам не нужен.

Конечно оно работает

наверное у разных людей понятие «работает» таки разное. То что сделали - это вытащили из OS в API пару методов, а все остальное - это для сильных духом уже, т.е. понятно, что кроме «read, flip, write», в обработчике должна быть какая-то еще логика + поддержка протокола верхнего уровня и оно как-то вообще в эти «read, flip, write» не влезает. В netty по сути аж целый фреймворк запилили, чтобы с этим можно было хоть как-то работать на практике.

вероятно проблема в том, что of - так себе название для статического метода

Да не, там прямо по комитам видно, что сначала запилили оф, а потом стало ясно что нужен офнуллабл. Так нет чтобы с оф чек убрать..

Гойц пишет как предполагалось использовать Optional

Мало ли как предполагалось, ну тупняк же так делать.

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

вероятно проблема в том, что of - так себе название для статического метода: в случае import static оно будет вызывать массу проблем, а вот ofNullable уже можно как-то связать с Optional

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

Статические импорты это одна из самых важных фич жавы, позволяющая не сойти с ума.

Не сойти со скуки, разве что. Скопируешь, бывает, кусок кода и гадаешь, что там за of() (List? Map? MyCustomShit?) или где живет someRandomMethod().

Какой идиот будет делать опшенал поле?

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

Опшенал не для этого же.

А это уже вопрос философский. https://www.башорг.рф/quote/415620

А опшенал это нуллсейф курильщика.

О чём я и написал.

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

Ну и, да, импортировать нужно имена, по которым понятно, что они делают. of к таким не относится. А вот parseInt относится.

Идея при копировании кода запоминает, что откуда импортировалось.

Не замечал такого.

Ну и, да, импортировать нужно имена, по которым понятно, что они делают. of к таким не относится. А вот parseInt относится.

Угу, и при нормальных функций получить SuperDuper.creatSuperDuper(). Но это не про то что я говорил. Есть ф-ция createSuperDuper() — понятно что она делает, но не понятно где она живет.

Кстати, а чем, по твоему мнению, нестатический импорт хуже статического?

Угу, и при нормальных функций получить SuperDuper.creatSuperDuper(). Но это не про то что я говорил. Есть ф-ция createSuperDuper() — понятно что она делает, но не понятно где она живет.

SuperDuper тоже непонятно где живёт. Давай запретим импорты в принципе? Ровно та же логика.

Что непонятного-то? Если ты в IDE, наводишь мышкой и тебе покажет. Сейчас даже гитхаб подобное умеет. Если ты в блокноте - ну перемотай на верх файла и найди импорт.

Кстати, а чем, по твоему мнению, нестатический импорт хуже статического?

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

SuperDuper тоже непонятно где живёт.

1. Названия классов в разы уникальней чем ф-ции.
2. Ты предлагаешь дублировать SuperDuper и в названии ф-ции и в названии класса.

Давай запретим импорты в принципе? Ровно та же логика.

Было не плохо. Но имя пакета слишком длинное. Потому, всегда есть предел.

Что непонятного-то? Если ты в IDE, наводишь мышкой и тебе покажет. Сейчас даже гитхаб подобное умеет. Если ты в блокноте - ну перемотай на верх файла и найти импорт.

Покажет если у тебя уже есть это зависимость. Код копируют и между проектами и из интернета даже.
Кандидатов может быть несколько (см. тот же of()).

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

Извини, не верю. listOf() короче List.of() аж на целую точку.
Конечно, если писать в духе List.listOf() то да, короче. Но это проблема популярного в java-тусовке стиля

String userData = userService.findUser(userId).getUserData();

1. Названия классов в разы уникальней чем ф-ции.

Далеко не всегда. Да это и не важно. Важно, чтобы из названия функции было понятно, что она делает.

2. Ты предлагаешь дублировать SuperDuper и в названии ф-ции и в названии класса.

Не предлагаю.

Было не плохо. Но имя пакета слишком длинное. Потому, всегда есть предел.

И этот предел в другой стороне.

Покажет если у тебя уже есть это зависимость. Код копируют и между проектами и из интернета даже.

Про копирование уже сказал - IDE всё нормально копирует. Из интернета - там и обычные импорты надо резолвить. Если ты настаиваешь на некоем StackOverflow-friendly style, который поможет другим копировать твой код наиболее безболезненно, ок, спорить не буду. Свой стиль кода я оптимизирую для последующего чтения, а не для последующего копирования не пойми откуда.

Кандидатов может быть несколько (см. тот же of()).

Я не предлагаю статически импортировать of. И не предлагаю статически импортировать всё. Я предлагаю статически импортировать те функции, в которых имя класса не добавляет никакой информации. В List.of имя класса добавляет информацию, его статически импортировать не надо. В SuperDuper.createSuperDuper - надо. В Integer.parseInt - надо.

Извини, не верю.

Это не вопрос веры, это вопрос подсчёта количества символов.

Конечно, если писать в духе List.listOf() то да, короче. Но это проблема популярного в java-тусовке стиля

Другой java-тусовки на этой планете у меня нет.

В Integer.parseInt - надо.

Это баг в дизайне ждк. Оно должно было бы называться Integer.parse(). До них потом дошло, и они уже делают List.of(). Им стоит объявить parseInt() устаревшим и ввести для нее замену parse().

Другой java-тусовки на этой планете у меня нет.

Ну так в рамках проекта же можно строить свою тусовку. Благо, что и ЖДК (да и вся тусовка) идет в ту же сторону. Пошла мода на Users.* вместо UserUtils.* и т. п.

Это баг в дизайне ждк. Оно должно было бы называться Integer.parse(). До них потом дошло, и они уже делают List.of(). Им стоит объявить parseInt() устаревшим и ввести для нее замену parse().

Я не думаю, что они когда-либо это сделают.

Вот некоторые из моих статических импортов. Уверен, что они никогда не поменяются.

import static java.nio.charset.StandardCharsets.UTF_8;
import static java.util.Objects.requireNonNull;
import static org.springframework.http.MediaType.TEXT_XML;

import static javax.xml.datatype.DatatypeConstants.FIELD_UNDEFINED;
import static javax.xml.transform.OutputKeys.ENCODING;
import static javax.xml.transform.OutputKeys.METHOD;
import static javax.xml.transform.OutputKeys.OMIT_XML_DECLARATION;
import static javax.xml.xpath.XPathConstants.NODESET;
import static org.w3c.dom.Node.ELEMENT_NODE;


import static java.time.ZoneOffset.UTC;
import static software.amazon.awssdk.core.checksums.RequestChecksumCalculation.WHEN_REQUIRED;

Да, тут большинство это константы, но и методы присутствуют. Objects.requireNonNull этот метод был добавлен относительно недавно, тем не менее тут имя класса не имеет никакого смысла, в то время как имя метода на 100% описывает то, что он делает.