Вай нот, если в коллекторе есть логика, которую нельзя выразить стримовыми промежуточными операциям

Так есть же streamex: https://github.com/amaembo/streamex/blob/master/CHEATSHEET.md#basic-collectors

Не работает?

а чем оно отличается от обычного коллектора? судя по имплементации это тоже самое

используй спарк, там есть пары

или напиши свою пару и свой мап

потом заредьюсишь по ключу

вот тебе и партишонинг

Кхм. Это действительно collector. Похоже, streamex отличается от обычного тем, что там «Short circuiting reduction» (см http://amaembo.github.io/streamex/javadoc/one/util/streamex/package-summary.html )

> For some operations like groupingBy it's impossible to create a short-circuiting collector even if the downstream is short-circuiting, because it's not known whether all the possible groups are already created.

тоже самое что я написал в самом начале

Я так понимаю типа такого вопрос https://stackoverflow.com/questions/24474838/can-i-duplicate-a-stream-in-java-8 ?

По факту основная проблема будет в невозможности раздедения терминального оператора

всем привет
есть следующая задача: эндпоинт, который принимает JSON и как-то обрабатывает значения на любой степени вложенности
например

{
  "DASHBOARD": "view_dashboard",
  "DEVICES": {
    "CREATE": "c_device",
    "LIST": "l_device",
    "UPDATE": "u_device",
    "DELETE": "d_device"
  }
}

и я верну что-то вроде:

{
  "DASHBOARD": true,
  "DEVICES": {
    "LIST": true,
    "UPDATE": true
  }
}

я конечно могу намутить обход json-чика, но может есть готовые какие-нибудь решения для такого?

Всем привет! кто хорош в spring batch job? Есть короче задача, идет запрос от клиента. В процесее этого запроса идет последовательное общение к нескольким урлам стороннего сервиса. не хочу делать синхронно, ибо каждый урл стороннего сервиса может отрабатывать минуту, а всего таких запросов около 7

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

Еще вопрос по премежуточным данным. То есть допустим степу 3 нужна инфа, которая получается в результате выполенения степ 1. норм ли сохранять в бд эту инфу, а не JobContext-е?

норм
норм

но вообще это не на батч больше похоже, а на stream processing(Kafka Streams и прочее подобное)

можно и на camel'е сделать, если это привычнее

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

да батч тоже не особо - слишком большой оверхед на таких маленьких задачах

В принципе да. В зависимости от предиката пустить элементы в разные стримы.

Я одного не понимаю: «принципиалтно невозможно не коллектить», окей, соглашуть, но sorted() именно это и делает? Просто внутри.