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(a)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(a)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(a)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(a)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(a)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(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.
>> >
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>> _______________________________________________
>> 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.