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

[John D. Ament]

I agree that it's a sorely missing feature.  Jumping in to how to
standardize it is how we got into this problem.  From what I remember it
was agreed to use the lowest entry point.
On Mar 6, 2016 12:51, "Reza Rahman" <reza_rahman at lycos.com> wrote:

> Personally I think this is overdue for standardization, it's just that
> it's a rather strange API choice I'd like to at least understand a bit
> better. What was the thinking behind this?
>
> On Mar 6, 2016, at 12:24 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>
> 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.
>>
>
>
> _______________________________________________
> 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/53446e31/attachment.html