всем привет, есть вопрос по многопотоку

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

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

Можно последние звенья писать синхронными, например, вызов стороннего реста, а вот на более высоком уровне это оборачивать в фичи/реакт/стримы. Нужно смотреть, что апи должно возвращать, если результат нужен вот прямо сейчас, то без промис-обёрток не получится сделать(без велосипедов), имхо

Можно последние звенья писать синхронными, например, вызов стороннего реста, а вот на более высоком уровне это оборачивать в фичи/реакт/стримы. Нужно смотреть, что апи должно возвращать, если результат нужен вот прямо сейчас, то без промис-обёрток не получится сделать(без велосипедов), имхо

я хочу отвязать все слои, и при этом не начать блокировать

что-то типа async в js или suspending function в котлине

Может в реактивщину глянуть тогда уж? А то на один запрос еще несколько тредов появится, еще хуже для масштабирования.

реактивщина не решит эту проблему(
просто я буду возвращать не CompletableFuture а Mono

реактивщина не решит эту проблему(
просто я буду возвращать не CompletableFuture а Mono

Хорошо бы прояснить, откуда и куда возвращаются данные? По разным слоям или на одном слое, но между разными объектами?

А чем Моно плохо? В ЖС ты бы возвращал промис но это ок?

в жс я бы делал async await и явно бы не использовал промисы

ну так ты бы явно обявлял бы все функции в цепочке вызовов как async/await и когда надо то собирал бы сам промис и возвращал его. те все тоже самое.

да но без коллбеков или джоинов на каждом уровне, внутри этой иерархии

А в чём разница? Если просто не задавать jvm ключи?

поэтому и предлагают Mono/Flux где будешь делать flatMap, нет в джаве сахара для асинхронщины. жди project loom

не понимаю, как это мне поможет принцип ведь тот же?
просто вместо CompletableFuture.thenCompose будет Mono.flatMap?

ps. реактивщиной я раньше не занимался