2:55 a.m.
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.
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...
<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...
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> 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
<mailto:jharting@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(a)gmail.com
<mailto:sven.linstaedt@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(a)gmail.com
<mailto:rmannibucau@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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
<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
<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 <mailto:cdi-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
<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
<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.