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

[Romain Manni-Bucau]

2016-03-06 18:02 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:

> What I think would be even better is to see this implemented in the impls
> (Weld & OWB) and see how users use it, in a release that's not plastered
> with Alpha or Experimental all over it.  While I think we were all wary
> about it, we need real end user input from the impl standpoint to figure
> out what makes sense to standardize on.
>
>
Or just do the opposite and *standardize* it. We can use Rx* feedbacks but
it doesnt' match event case at all which is a real small subset of the
reactive programming so I guess easiness should be what drives us there and
integration at least with the JVM so CFuture version sounds more natural
than CStage one. Difference is very small at method level but at utility
level it is.

Side note: a Weld or OWB release without experimental/alpha sounds worse if
the spec changes later. A compromise can be an extension doing it already
you can drop in any of these containers.


> John
>
>
> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman <reza_rahman at lycos.com> wrote:
>
>> How much end user feedback has there been on this? I have to be honest
>> that it surprises me to find this out now.
>>
>> This to me stands out as an obvious usability problem. CompletableFuture
>> is the obvious top level end user API, not CompletionStage. 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>
>> 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
>> 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.
>
>
> _______________________________________________
> 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/20160306/e887522a/attachment.html