In a non-blocking application flow, it's desirable to prevent event listeners from blocking and yet have a notion of managed event completion (i.e. an event listener needs to interact with a remote system but must not block). Event listener methods could return future/async types so the event multicaster can synchronize on execution/initiate execution to use non-blocking event listeners in a reactive (or at least non-blocking) arrangement.
Event listener methods could either return:
A future (in particular ListenableFuture, CompletableFuture, or CompletionStage, either Void, T, or Collection<T> component types)
A Publisher (or any other supported reactive type such as RxJava 2's Observable with Void or T component types).
This feature could allow to implement functionality in event listeners in an non-blocking programming model to prevent blocking calls.
Result handles should be used to attach at least some sort of exception handling to prevent exceptions from going unnoticed. For reactive types, the multicaster subscribes to the reactive type to materialize the outcome.
Values emitted from a result handle (i.e. non-void returns like CompletableFuture<Void>, Publisher<Void>) could be emitted again as events.
Since each such listener is conceptually independent, should we simply subscribe to each returned Publisher individually? Would we have to manually exhaust the publisher through subscription.request(Long.MAX_VALUE) and publish each item as an event in onNext?