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

Sun Mar 6 14:55:03 EST 2016

On the flip side, it seems like CompletionStage isn't quite a complete API,
and if external callers can only leverage a specific impl then its more of
a case where the interface does not enough.

John

On Sun, Mar 6, 2016 at 1:48 PM Reza Rahman <reza_rahman at lycos.com> wrote:

> Using the lowest level API possible on principal seems to be the only
> justification that I can see. Almost by definition that's causing a
> usability hazard in this case. This is easily avoided by using the more
> likely familiar higher level API. It introduces no complexities for
> implementation or standardization.
>
> On Mar 6, 2016, at 1:39 PM, John D. Ament <john.d.ament at gmail.com> wrote:
>
> 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.
>>
> _______________________________________________
> 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/a529b1a4/attachment-0001.html 