[cdi-dev] async activation on observers, why not CompletableFuture

Wed Apr 1 13:54:10 EDT 2015

2015-04-01 19:43 GMT+02:00 José Paumard <jose.paumard at gmail.com>:

> CompletionStage has a toCompletableFuture() method, that returns a
> CompletableFuture. So there is no limitation in returning CompletionStage.
> It could allow different implementation in the future than the only one we
> have so far : CompletableFuture, since one can build a CompletableFuture
> that wraps another implementation.
>
>
+1, missed it


> Problem with CF.allOf() and anyOf() is that they return resp. CF<Void> and
> CF<Object>, which is not very API friendly.
>
>
it is enough in enough cases IMO


> Having the observers writers to provide his own implementation of
> CompletableFuture is not that great imho. For the async EJB, all you can do
> is return executorService.submit(myTask). I understand why the API
> designers have chosen that, but I dont think it's that great. Correct me if
> I'm wrong, but I think that we have the opportunity to move that burden
> from the observers writers to the framework. And I think it would make the
> API easier to use.
>
>
What's your proposal? EJB API is quite nice to use and it integrates
smoothly with Future<>, not sure I get what's your issue is here.


> José
>
>
> 2015-04-01 10:08 GMT+02:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>
>> Hello Antoine,
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> <http://www.tomitribe.com>
>>
>> 2015-04-01 9:55 GMT+02:00 Antoine Sabot-Durand <antoine at sabot-durand.net>
>> :
>>
>>> Hi Romain,
>>>
>>> Intersting proposal. As I felt reading you that we misse the
>>> CompletableFuture stuff in Java 8, I just repeat here that the agreed on
>>> fireAsync signatures
>>>
>>> <U extends T> CompletionStage<U> fireAsync(U event);
>>> and
>>> <U extends T> CompletionStage<U> fireAsync(U event, Executor executor);
>>>
>>> Yeah it’s CompletionStage because Jozef preferred using interfaces in
>>> our API, but I guess implementation will use CompletableFuture under the
>>> hood to avoid reinventing the wheel.
>>>
>>>
>> This sounds "normal" but JVM doesn't follow it with its utility methods
>> so basically today CompletionStage is super poor compared to
>> CompletionFuture so I'm tempted to say the impl is preferred here. I didn't
>> check what is the adoption of both in other framework, can validate or not
>> my thought maybe.
>>
>>
>>> With this approach your example:
>>>
>>> event.fireAsync(new LetTheWorldKnow()).thenRun(() ->
>>>> System.out.println("We did it!"));
>>>>
>>>
>>> will work without adding constraint on observer signature.
>>>
>>> Regarding the observer part, we already discuss similar approach. In a
>>> former version of my async event doc I proposed using return type on
>>> observer to do discrimination between async and sync and Mark made a
>>> suggestion near yours during this meeting:
>>>
>>>
>>> http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-02-25-17.06.log.html
>>>
>>> (search for the first “signature” in text)
>>>
>>> The main drawback of this approach is to let end user generate the
>>> returned CompletableFuture. So each async observer should provide a way to
>>> construct this completableFuture. The second question is the type param of
>>> the returned CompletableFuture. Should we use raw type? Now we could
>>> imagine helped to do that but...
>>>
>>>
>> Exactly why I think this is a better solution. Cause it opens the door to
>> asynchronism in a more elegant manner handling completion properly. I guess
>> first impl will use allOf() combination but I see anyOf() - i fire to
>> "notifiers" and I care only of 1 at least being called as a caller - and
>> potentially other combinations other potentials needs we could cover in
>> another spec (hopefully).
>>
>> If async is just fire and forget we don't need fireAsync() but only
>> fire() (void) and then observers are async or not which ensures compat at
>> all levels since observers decide to be in the same context or not but I
>> guess we don't want only fire and forget.
>>
>> About creating a CompletableFuture we can do as in EJB spec and provide
>> version to use by observer impl (javax.ejb.AsyncResult).
>>
>>
>>> Don’t get me wrong, I’d love to find a solution based on this kind of
>>> idea, but I fear it will add more complexity than double activation.
>>>
>>> Antoine
>>>
>>>
>>> Le 1 avr. 2015 à 09:15, Romain Manni-Bucau <rmannibucau at gmail.com> a
>>> écrit :
>>>
>>> No, fireAsync is still needed for all the reason we mzntionned -
>>> strongest one being the fact we need a return type and cant change fire -
>>> but using the return type we have the double activation without introducing
>>> a new API. Said otherwise API stays natural on both sides which was my main
>>> fear with a fireAsync and an @ObservesAsync (or any other new api we talked
>>> about). And we have the bonus to be aligned on SE async which sounds quite
>>> interesting for the future.
>>> Le 1 avr. 2015 08:48, "Jozef Hartinger" <jharting at redhat.com> a écrit :
>>>
>>>>  So instead of calling observers asynchronously you suggest turning
>>>> observers into producers of CompletableFuture that will then be completed
>>>> asynchronously?
>>>>
>>>> On 03/31/2015 06:21 PM, Romain Manni-Bucau wrote:
>>>>
>>>> // fire side
>>>> event.fireAsync(new LetTheWorldKnow()).thenRun(() ->
>>>> System.out.println("We did it!"));
>>>>
>>>>  // observer side
>>>> CompletableFuture iWantToKnow(@Observes LetTheWorldKnow event) {}
>>>>
>>>>  // impl behavior would be like
>>>> CompletableFuture.allOf(allObserverReturnedInstances) to be aligned on
>>>> CompletableFuture behavior I think
>>>>
>>>>  Am I clearer?
>>>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <http://rmannibucau.wordpress.com/> | Github
>>>> <https://github.com/rmannibucau> | LinkedIn
>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>> <http://www.tomitribe.com/>
>>>>
>>>> 2015-03-31 18:15 GMT+02:00 Sven Linstaedt <sven.linstaedt at gmail.com>:
>>>>
>>>>>  Hi Romain,
>>>>>
>>>>>  I am not sure, I have fully understand how an observer with CompletableFuture could
>>>>> look like. Could you give us an example?
>>>>>
>>>>>  Afair CompletableFuture was considered to be used in the "trigger"
>>>>> side in order to track async event invocation completion.
>>>>>
>>>>>  br, Sven
>>>>>
>>>>>  2015-03-31 18:00 GMT+02:00 Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>> :
>>>>>
>>>>>>  Hi guys,
>>>>>>
>>>>>>  on async topic if I followed we are at the point where we are
>>>>>> looking for an activation on the observer side.
>>>>>>
>>>>>>  Since Java 8 has now CompletableFuture it would be great to use it.
>>>>>> Today the spec doesnt use observer returned values so it is mainly a bad
>>>>>> practise to have one even if not strictly forbidden - BTW never saw it in
>>>>>> real applications - plus spec is not compatible - not specified at all -
>>>>>> with CompletableFuture since it is a new API so we can use it as a marker.
>>>>>>
>>>>>>  This is quite interesting for few reasons:
>>>>>> 1- we have our double activation
>>>>>> 2- API is user friendly (observer is async and has an async signature)
>>>>>> 3- open door for future async enhancements (hopefully not in CDI)
>>>>>> with composition of these observers
>>>>>>
>>>>>>
>>>>>>  Only point I'm not sure is should these observers support sync
>>>>>> events. I don't see anything blocking to do it but can have missed
>>>>>> something.
>>>>>>
>>>>>>
>>>>>>  wdyt?
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>> <http://rmannibucau.wordpress.com/> | Github
>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>>> <http://www.tomitribe.com/>
>>>>>>
>>>>>>  _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>> Note that for all code provided on this list, the provider licenses
>>>>>> the code under the Apache License, Version 2 (
>>>>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>> ideas provided on this list, the provider waives all patent and other
>>>>>> intellectual property rights inherent in such information.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>
>>>>
>>>>  _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2 (
>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual property rights inherent in such information.
>>>
>>>
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>
>
>
> --
> Java le soir <http://blog.paumard.org> Cours Java en ligne
> <http://blog.paumard.org/cours-tutoriaux/>
> Twitter <http://twitter.com/#!/JosePaumard> Paris JUG
> <http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
> M : +33 6 76 82 91 47
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/fded9bf6/attachment-0001.html