А получится ли эффективно обрабатывать миллион одновременных задач, если каждая лезет на ФС/в БД/куда-то ещё? Я к тому, что вряд-ли все зависимые компоненты, с которым будет работать наше мнимое приложение с виртуальными потоками под капотом, смогут принять эти миллионы. Высока вероятность всё положить. Значит придётся ограничивать количество одновременно обрабатываемых соединений, а тогда уже и особого смысла нет в легковесных нитях, получаются почти те же пулы потоков. А вообще конечно надо дождаться, когда завезут и смотреть уже в каждом конкретном случае.

Очень похоже, что это код из идеи вместе с её подсказками выводимых типов. На стриме Алан демки показывал именно в ней.

Выглядит многообещающе для самого java-приложения. Но я вот не понимаю одного: выигрыш здесь от I/O-операций и им подобных, это значит, что приложение будет взаимодействовать с другими компонентами, например БД или другой микросервис. Пул потоков, от которого предлагают отказаться, предоставляет удобный способ настраиваемо ограничивать количество одновременных операций, выполняемых на взаимодействующей стороне. На его фоне предлагаемые ручные блокировки как ограничитель выглядят вообще велосипедом. (Или они действительно предлагают позволить приложению постоянно выполнять миллионы запросов в БД?)

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

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

Именно тут на страже стоят unit тесты, которые фиксируют утвержденные правила, по которым должна работать система!

Систему целиком контролируют IT-тестами, никак не unit. Поэтому если времени в обрез, лучше тратить его на IT-тесты, от них выхлопа больше

“у нас есть метод, который подсчитывает сумму чисел”
“на данный метод можно написать тест”

В статье скатились в тоже самое, только тестирование спринга добавилось.

Какова подача сего факта в статье: может глюкануть — прям поражает. Я не понимаю, за что так заплюсовали статью? За описанное поведение?

На счёт документации — её не обязательно читать всю на свете. Нужно читать и изучать как минимум то, что используешь здесь и сейчас.

Я думаю это оно и есть, но там структура описывается кодом вручную. Прям напрашиваются библиотеки типа jackson json, которые будут десериализовывать структуру в памяти в java-объект по (возможно аннотированному) классу, как раз используя Memory Access/Layout APIs.

New Option Added to jcmd for Writing a gzipped Heap Dump (JDK-8237354)

Лучше поздно, чем никогда :) уже поднадоело сначала ждать, пока процесс запишет дамп, потом ужимать, потом перекидывать… Хоть один шаг сократили.

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

Тяжело стало на руках-то держать, да? :))
Присоединяюсь к проздравлениям!

Интересная новость про Project Leyden.

Из всего мне не понятно вот это:

достижения пиковой производительности
Предполагается генерить статические образы JDK

в моём понимании пиковую производитеность даёт JIT после некоторого прогрева. Они собрались вшивать JIT? Или как-то выполнять код во время сборки? Последний вариант вроде как и толще бинарь выдаст.

Что вы так переживаете, конечно читают! Вы же видите сколько просмотров у ваших статей :)

ждала еще одна неожиданность, а именно что для работы упаковщика в среде Windows необходимо дополнительно установить WiX

В JEP 343, на который вы ссылаетесь, в последней секции Dependencies явно же написано:

Wix, a third-party tool, is required to generate msi or exe packages

Вроде бы вот этот черновик

А вообще, в этой статье человек лучше меня объяснил этот феномен)
Неизменяемых коллекций в Java не будет – ни сейчас, ни когда-либо

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

JEP 343. Упаковщик jpackage (Инкубатор)

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

Есть такая штука в Java, как JFR — Java Flight Recording — фиксация событий «на лету», которая позволяет мониторить около 500 разновидностей событий во время работы приложения. Проблема в том, что большинство из них можно посмотреть только в логах.

Я думал jfr может только в бинарь писать...

Exception in thread "main" java.lang.NullPointerException: Cannot assign field "cities" because "countries" is null
at Main.main(Main.java:21)

Мне не понятно, почему сообщение ссылается на поля, а не на методы. А если геттер возвращает вообще другое поле/сам что-то вычисляет или вообще сам возвращает null?

Ага, вот прекратили поддержку, и мы все дружно бежим выбрасывать старые компы и покупать новые, чтобы на них новая ОС завелась…

Так M$ и на это рассчитывает...

Я вот не вижу никаких принципиальных причин, почему невозможно продолжать писать ПО

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

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

Я думал и правда свечение будет как на КДПВ! А там получается белая точка. Но всё равно достаточно интересное явление, тоже благодарю за интересное приключение. Даже видеоверсию посмотрел, что делаю редко в случае статей.

Для случаев, когда есть только один is*, можно использовать Predicate.not вместо отрицания:

long emptyCount = stream
    .filter(not(Optional::isPresent))
    .count();

Как отсюда вытащить цифру 8? Наверное, надо взять java.specification.version, отбросить 1., потом сконвертировать строку в число… Но не торопитесь, потому что на Java 9 это всё сломается:
…
Однако не печальтесь, потому что в Java 9 появилось нормальное API для получения версий

Поэтому на восьмёрке продолжаем строить велосипед.

Кто вам такое сказал?