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
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@gmail.com
> <mailto:rmannibucau@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@lists.jboss.org <mailto:cdi-dev@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@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@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.