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

2015-04-01 21:46 GMT+02:00 José Paumard <jose.paumard(a)gmail.com&gt;: > > 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. > EJB has me to write this kind of code : > > return es.submit(myTask) ; > > this looks wrong, return new AsyncFuture<String>("i did it"); is what you should have written otherwise you just didnt use EJB async feature.

> Because this is a synchronous call, that has to return a Future. But on > the other hand this is purely tehcnical code, that cant be put in the > framework, since one can call directly an EJB method. So the return type > has to be the one of the EJB method. > > With events the situation is different. On the calling side, I write > > completableFuture = event.fireAsync(payload) ; // type is > CompletionStage<probably void since there are many observers and an allOf > call> > > On the observing side I can write : > > public T observes(@Observes payload) { return t ; } > > And the framework will take care of wrapping this t in a > CompletableFuture.allOf(...) with all the other observers to return it. So > I dont have to deal myself with the technical aspects of calling ES myself. > IMHO it leads to easier to write patterns. > Why T then? And actually your explanation is my proposal but a on purpose typing. > > José > > > > 2015-04-01 19:54 GMT+02:00 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt;: > >> >> >> 2015-04-01 19:43 GMT+02:00 José Paumard <jose.paumard(a)gmail.com&gt;: >> >>> 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(a)gmail.com&gt;: >>> >>>> 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(a)sabot-durand.net&gt;: >>>> >>>>> 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-de... >>>>> >>>>> (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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; >>>>>> : >>>>>> >>>>>>> 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(a)gmail.com&gt;: >>>>>>> >>>>>>>> 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(a)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@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(a)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(a)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 >>> >> >> > > > -- > 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 >