Здравствуйте, dsorokin, Вы писали:

D>И заметь одну важную вещь. Почти нигде в документации в подобных случаях не указывают на прямую связь ФП. Если тебе напишут, что Java Stream — это моноид, то тебе такое понравится?

А как ответить на такой вопрос: если из этого моноида вызвать транзакционный jpa-код, к какому треду и связанному с каким тредом и tx-менеджером его соотнесет EE-фреймворк, от этого ведь будет зависеть логика коммита/отката? И вообще, этот моноид исполняется на треде реквеста или на вторичном треде из некоего пула? А этот пул какой вместимости? Не станет ли он узким местом? А с секьюрностью что будет, если секьюрити контекст с авторизацией привязан к треду реквеста, он што, потеряется и тред моноида будет выполняться анонимно? Значит, код моноида подвержен атакам? Секьюрность контекста у моноида вообще можно обеспечить гарантией java sdk, как у классического threadlocal, или это обеспечивается лишь псевдо-гарантией на уровне самописных реактивных библиотек? А шо там у моноидов с OneToMany/ManyToMany? Не поддерживается, и нужно вручную реализовывать? Надо же, какая досада, но зато функционально! А шо там у них с пробросом эксепшнов? А стектрейс человеческий (кто это когда и с чем по цепочке вызвал) можно посмотреть без установки в ide спец-приблуд? Нельзя, но зато функционально!
Столько вопросов, столько рисков, это же не просто голые computation, может надёжнее не открывать эту кротовую нору и писать enterprise-код в общепринятом процедурном стиле с анемичной моделью?