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

Reza Rahman reza_rahman at lycos.com
Mon Mar 7 10:51:57 EST 2016


If still in doubt, a wise move on this is to seek guidance from the JDK team. We shouldn't be doing things contrary to what their API design intent is. Their API design positioning is what folks out there are picking up and running with.

> On Mar 7, 2016, at 8:22 AM, Reza Rahman <reza_rahman at lycos.com> wrote:
> 
> If you don't understand why most developers would simply expect to use CompletableFuture and would immediately be confused if they see something else, I think we are in bigger trouble than I thought.
> 
> You should really ask a few developers outside your immediate network or do a Google search to see just how much more prominent CompletableFuture is as oppose to CompletionStage. Not finding a way to use that API and choosing an obscure superclass is a sure recipe for problems.
> 
>> On Mar 7, 2016, at 5:12 AM, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>> 
>> 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/e25e8d63/attachment.html 


More information about the cdi-dev mailing list