[cdi-dev] async: back to completion future?

[Antoine Sabot-Durand]

Hi guys,

Back from vacation, I'm "happy" to see that we go back on Async event
feature (which took us 6 months).

@Reza and @Romain sorry but I don't get it. the good practice is to develop
for interface (that's why CDI uses Set and not HashSet for instance). I'm
ok it's the theory, but if you want to make an exception to this practice
you need to have a good reason.  So if you want to rely on JDK classes like
CompletableFuture instead of interface, you'll probably have to go a step
further than that. CompletionStage has a toCompletableFuture() method.

To go back to the big picture, as some people around don't seem to be happy
with what we designed,  we still have the solution to move async event can
in specification annexe. It's  a solution to test a feature without
definitely specifying it.

Antoine

Le lun. 7 mars 2016 à 08:42, Martin Kouba <mkouba at redhat.com> a écrit :

> Dne 6.3.2016 v 16:37 Reza Rahman napsal(a):
> > How much end user feedback has there been on this? I have to be honest
> > that it surprises me to find this out now.
>
> Well, this was discussed many times (ML, EG mtgs, F2F, etc.).
>
> >
> > This to me stands out as an obvious usability problem. CompletableFuture
> > is the obvious top level end user API, not CompletionStage.
>
> Is it obvious? For me the CompletionStage looks more appropriate. But
> I'm open for discussions.
>
> > Not going
> > with CompletableFuture is very likely to confuse most people. The last
> > thing we need is more potential usability problems in Java EE APIs.
> >
> > On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau <rmannibucau at gmail.com
> > <mailto:rmannibucau at gmail.com>> wrote:
> >
> >> Hi guys,
> >>
> >> as a user having a ComlpetionStage makes me loose some JDK utilities,
> >> can we move back to CompletionFuture?
> >>
> >> It would allow for instance:
> >>
> >> // doesn't work with CompletionStage
> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...))
> >>       .then(...)
> >>
> >> 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 <mailto: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.
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> 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/20160307/c822e952/attachment.html