А получится ли эффективно обрабатывать миллион одновременных задач, если каждая лезет на ФС/в БД/куда-то ещё? Я к тому, что вряд-ли все зависимые компоненты, с которым будет работать наше мнимое приложение с виртуальными потоками под капотом, смогут принять эти миллионы. Высока вероятность всё положить. Значит придётся ограничивать количество одновременно обрабатываемых соединений, а тогда уже и особого смысла нет в легковесных нитях, получаются почти те же пулы потоков. А вообще конечно надо дождаться, когда завезут и смотреть уже в каждом конкретном случае.
Выглядит многообещающе для самого java-приложения. Но я вот не понимаю одного: выигрыш здесь от I/O-операций и им подобных, это значит, что приложение будет взаимодействовать с другими компонентами, например БД или другой микросервис. Пул потоков, от которого предлагают отказаться, предоставляет удобный способ настраиваемо ограничивать количество одновременных операций, выполняемых на взаимодействующей стороне. На его фоне предлагаемые ручные блокировки как ограничитель выглядят вообще велосипедом. (Или они действительно предлагают позволить приложению постоянно выполнять миллионы запросов в БД?)
Среди разработчиков бытует справедливое мнение, что если программист не покрывает код тестами, то попросту не понимает зачем они нужны и как их готовить.
Кажется, разработчики как раз понимают. Не понимает начальство. Жду статью, как заставить начальство понять и выделить ресурсы на написание и поддержку тестов...
Именно тут на страже стоят unit тесты, которые фиксируют утвержденные правила, по которым должна работать система!
Систему целиком контролируют IT-тестами, никак не unit. Поэтому если времени в обрез, лучше тратить его на IT-тесты, от них выхлопа больше
“у нас есть метод, который подсчитывает сумму чисел”
“на данный метод можно написать тест”
В статье скатились в тоже самое, только тестирование спринга добавилось.
Я думаю это оно и есть, но там структура описывается кодом вручную. Прям напрашиваются библиотеки типа jackson json, которые будут десериализовывать структуру в памяти в java-объект по (возможно аннотированному) классу, как раз используя Memory Access/Layout APIs.
достижения пиковой производительности
Предполагается генерить статические образы JDK
в моём понимании пиковую производитеность даёт JIT после некоторого прогрева. Они собрались вшивать JIT? Или как-то выполнять код во время сборки? Последний вариант вроде как и толще бинарь выдаст.
А вообще, в этой статье человек лучше меня объяснил этот феномен)
Неизменяемых коллекций в Java не будет – ни сейчас, ни когда-либо
Где-то на просторах openjdk читал, что иметь у каждого объекта заголовок с синхронизацией расточительно и было бы неплохо переиспользовать его для других целей, в т.ч. и для флага заморозки. Правда не понятно что делать с существующим фреймворком коллекций, озвученных проблем с API это не решит. Но заголовок той статьи слишком резок, что ли..
Вроде всё красиво, одно не понятно: как запихнуть в пакет ресурсы приложения с фс,
то бишь произвольные файлы, которые надо положить в конкретное место.
Есть такая штука в 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?
Я думал и правда свечение будет как на КДПВ! А там получается белая точка. Но всё равно достаточно интересное явление, тоже благодарю за интересное приключение. Даже видеоверсию посмотрел, что делаю редко в случае статей.
Для случаев, когда есть только один is*, можно использовать Predicate.not вместо отрицания:
long emptyCount = stream
.filter(not(Optional::isPresent))
.count();
Как отсюда вытащить цифру 8? Наверное, надо взять java.specification.version, отбросить 1., потом сконвертировать строку в число… Но не торопитесь, потому что на Java 9 это всё сломается:
…
Однако не печальтесь, потому что в Java 9 появилось нормальное API для получения версий
Поэтому на восьмёрке продолжаем строить велосипед.
А получится ли эффективно обрабатывать миллион одновременных задач, если каждая лезет на ФС/в БД/куда-то ещё? Я к тому, что вряд-ли все зависимые компоненты, с которым будет работать наше мнимое приложение с виртуальными потоками под капотом, смогут принять эти миллионы. Высока вероятность всё положить. Значит придётся ограничивать количество одновременно обрабатываемых соединений, а тогда уже и особого смысла нет в легковесных нитях, получаются почти те же пулы потоков. А вообще конечно надо дождаться, когда завезут и смотреть уже в каждом конкретном случае.
Очень похоже, что это код из идеи вместе с её подсказками выводимых типов. На стриме Алан демки показывал именно в ней.
Выглядит многообещающе для самого java-приложения. Но я вот не понимаю одного: выигрыш здесь от I/O-операций и им подобных, это значит, что приложение будет взаимодействовать с другими компонентами, например БД или другой микросервис. Пул потоков, от которого предлагают отказаться, предоставляет удобный способ настраиваемо ограничивать количество одновременных операций, выполняемых на взаимодействующей стороне. На его фоне предлагаемые ручные блокировки как ограничитель выглядят вообще велосипедом. (Или они действительно предлагают позволить приложению постоянно выполнять миллионы запросов в БД?)
Кажется, разработчики как раз понимают. Не понимает начальство. Жду статью, как заставить начальство понять и выделить ресурсы на написание и поддержку тестов...
Систему целиком контролируют IT-тестами, никак не unit. Поэтому если времени в обрез, лучше тратить его на IT-тесты, от них выхлопа больше
В статье скатились в тоже самое, только тестирование спринга добавилось.
Какова подача сего факта в статье: может глюкануть — прям поражает. Я не понимаю, за что так заплюсовали статью? За описанное поведение?
На счёт документации — её не обязательно читать всю на свете. Нужно читать и изучать как минимум то, что используешь здесь и сейчас.
Я думаю это оно и есть, но там структура описывается кодом вручную. Прям напрашиваются библиотеки типа jackson json, которые будут десериализовывать структуру в памяти в java-объект по (возможно аннотированному) классу, как раз используя Memory Access/Layout APIs.
Лучше поздно, чем никогда :) уже поднадоело сначала ждать, пока процесс запишет дамп, потом ужимать, потом перекидывать… Хоть один шаг сократили.
Это всё детские примерчики. Мне вот интересно, можно ли будет описать сишную структуру в java-классе и натянуть байты на него.
Тяжело стало на руках-то держать, да? :))
Присоединяюсь к проздравлениям!
Интересная новость про Project Leyden.
Из всего мне не понятно вот это:
в моём понимании пиковую производитеность даёт JIT после некоторого прогрева. Они собрались вшивать JIT? Или как-то выполнять код во время сборки? Последний вариант вроде как и толще бинарь выдаст.
Что вы так переживаете, конечно читают! Вы же видите сколько просмотров у ваших статей :)
В JEP 343, на который вы ссылаетесь, в последней секции Dependencies явно же написано:
Вроде бы вот этот черновик
Где-то на просторах openjdk читал, что иметь у каждого объекта заголовок с синхронизацией расточительно и было бы неплохо переиспользовать его для других целей, в т.ч. и для флага заморозки. Правда не понятно что делать с существующим фреймворком коллекций, озвученных проблем с API это не решит. Но заголовок той статьи слишком резок, что ли..
Вроде всё красиво, одно не понятно: как запихнуть в пакет ресурсы приложения с фс,
то бишь произвольные файлы, которые надо положить в конкретное место.
Я думал jfr может только в бинарь писать...
Мне не понятно, почему сообщение ссылается на поля, а не на методы. А если геттер возвращает вообще другое поле/сам что-то вычисляет или вообще сам возвращает
null
?Так M$ и на это рассчитывает...
Весь этот груз под названием "легаси" всё труднее и труднее поддерживать так, чтобы при этом ещё новые плюшки завести. Желательно без костылей
Кому-то не захочется/не понравится тащить ещё одну зависимость в проект. Тем более если велосипед в пару строк, а может быть даже и тестом покрыт.
Я думал и правда свечение будет как на КДПВ! А там получается белая точка. Но всё равно достаточно интересное явление, тоже благодарю за интересное приключение. Даже видеоверсию посмотрел, что делаю редко в случае статей.
Для случаев, когда есть только один
is*
, можно использоватьPredicate.not
вместо отрицания:Поэтому на восьмёрке продолжаем строить велосипед.
Кто вам такое сказал?