[cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage

[Antoine Sabot-Durand (JIRA)]

    [ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119499#comment-13119499 ] 

Antoine Sabot-Durand commented on CDI-563:
------------------------------------------

My first idea was to go directly for {{CompletableFuture}} in our API (methods return type, etc...). [~jharting] raised concerns about using an impl where an API exist (I agreed with him) and features in CompletableFuture that we might not allow our users to have access to (I'm not sure to follow him there, especially when {{CompletionStage}} has a dependency on {{CompletableFuture}} with the {{toCompletableFuture()}} method).

So even if we won't expose CompletableFuture in our API for good practices, we won't reimplement what was nicely done in JDK8 and will use {{CompletableFuture}} under the hood. That's why I dont think we can say CDI will be an implementor of {{CompletionStage}}, we will be a user of {{CompletableFuture}} thru its main interface.
The only open question, IMO, is about default {{Executor}} used in {{CompletableFuture}} (based on fork/join if I'm not mistaken). [~mkouba], you're probably the best person to know if this default Executor is the best for us or if we should use our own {{Executor}} (CompletableFuture has methods to override default executor). 

So, unless I missed something, either we specify the behavior from default Executor in {{completableFuture}} or define ours. The user will always have the possibility to use her own Executor with the dedicated {{fireAsync()}} method.

> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
>                 Key: CDI-563
>                 URL: https://issues.jboss.org/browse/CDI-563
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Events
>    Affects Versions: 2.0-EDR1
>            Reporter: Martin Kouba
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)