From jharting at redhat.com Wed Apr 1 02:48:15 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 01 Apr 2015 08:48:15 +0200 Subject: [cdi-dev] async activation on observers, why not CompletableFuture In-Reply-To: References:

Message-ID: <551B94AF.4090208@redhat.com> 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 | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-31 18:15 GMT+02:00 Sven Linstaedt >: > > 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 > >: > > 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 | Blog > | Github > | LinkedIn > | Tomitriber > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/75058461/attachment.html From rmannibucau at gmail.com Wed Apr 1 03:15:30 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 1 Apr 2015 09:15:30 +0200 Subject: [cdi-dev] async activation on observers, why not CompletableFuture In-Reply-To: <551B94AF.4090208@redhat.com> References:

<551B94AF.4090208@redhat.com> Message-ID: 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" 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 | Blog > | Github > | LinkedIn > | Tomitriber > > > 2015-03-31 18:15 GMT+02:00 Sven Linstaedt : > >> 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 : >> >>> 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 | Blog >>> | Github >>> | LinkedIn >>> | Tomitriber >>> >>> >>> _______________________________________________ >>> 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/20d2643e/attachment-0001.html From antoine at sabot-durand.net Wed Apr 1 03:55:28 2015 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 1 Apr 2015 09:55:28 +0200 Subject: [cdi-dev] async activation on observers, why not CompletableFuture In-Reply-To: References:

<551B94AF.4090208@redhat.com> Message-ID: <1FAA4B03-6FB4-4998-9B33-958AF477E612@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 CompletionStage fireAsync(U event); and CompletionStage 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. 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... 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 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" > 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 | Blog | Github | LinkedIn | Tomitriber >> 2015-03-31 18:15 GMT+02:00 Sven Linstaedt >: >> 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 >: >> 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 | Blog | Github | LinkedIn | Tomitriber >> _______________________________________________ >> 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. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/e8b51dc1/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/e8b51dc1/attachment.bin From rmannibucau at gmail.com Wed Apr 1 04:08:35 2015 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Wed, 1 Apr 2015 10:08:35 +0200 Subject: [cdi-dev] async activation on observers, why not CompletableFuture In-Reply-To: <1FAA4B03-6FB4-4998-9B33-958AF477E612@sabot-durand.net> References:

<551B94AF.4090208@redhat.com> <1FAA4B03-6FB4-4998-9B33-958AF477E612@sabot-durand.net> Message-ID: Hello Antoine, Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-04-01 9:55 GMT+02:00 Antoine Sabot-Durand : > 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 > > CompletionStage fireAsync(U event); > and > CompletionStage 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 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" 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 | Blog >> | Github >> | LinkedIn >> | Tomitriber >> >> >> 2015-03-31 18:15 GMT+02:00 Sven Linstaedt : >> >>> 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 : >>> >>>> 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 | Blog >>>> | Github >>>> | LinkedIn >>>> | Tomitriber >>>> >>>> >>>> _______________________________________________ >>>> 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/7132ef4e/attachment-0001.html From jose.paumard at gmail.com Wed Apr 1 13:43:52 2015 From: jose.paumard at gmail.com (=?UTF-8?Q?Jos=C3=A9_Paumard?=) Date: Wed, 1 Apr 2015 19:43:52 +0200 Subject: [cdi-dev] async activation on observers, why not CompletableFuture In-Reply-To: References:

<551B94AF.4090208@redhat.com> <1FAA4B03-6FB4-4998-9B33-958AF477E612@sabot-durand.net> Message-ID: 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. Problem with CF.allOf() and anyOf() is that they return resp. CF and CF