[cdi-dev] [javaee-spec users] Re: Fwd: Re: CompletableFuture Usage in the Platfom vs CDI

Tue Mar 8 08:27:25 EST 2016

2016-03-08 14:22 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:

> I think the JDK team made the right usability call by including everything
> into CompletableFuture as a one stop shop. That's why the API will probably
> prove more usable in the end.
>
>
This is also about choosing the right level of exposed API.


> Can a developer erroneously call complete()? Sure, but it's pretty
> unlikely since it just doesn't fit the client usage pattern for a promise.
> And they can make this unlikely error either for @Asynchronous, CDI
> asynchronous events and pretty much just about anywhere CompletableFuture
> is used as an API.
>
>
In previous sample I would agree it is a programming error but in a real
application you can pass the future through several layers and then it is
less obvious (this async event opens a nice and fluent way to trigger an
event which is actually your returned data as well: return
asyncEvent.fireAsync(myResult);).


> That said, I've also reached out to the JDK team on this. I hope they will
> have the time to explain their design motivations themselves and clarify
> what they would expect from EE or just about anyone else needing to use
> their APIs.
>
>
Thanks


> On Mar 8, 2016, at 8:06 AM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
> @Reza: can you clarify the behavior of this snippet please:
>
> CompletionFuture<AnEvent> cf = asyncEvent.fireAsync(...);
> cf.complete(new AnEvent()); // not deterministic even if the container
> will likely get false calling complete, should it be ignored? throw an
> exception? other?
>
> That's one point where CompletionStage sounds wiser than CompletionFuture
> for CDI async events. The javadoc makes the goal clear: "@return a {@link
> CompletionStage} allowing further pipeline composition on the asynchronous
> operation.". Using CompletionFuture opens the door to the state
> manipulation which is not intended (or you have a plan for that?) and which
> is easily misleading IMHO.
>
> CompletionFuture would however make a lot of sense for some parts of EE
> and to replace @Asynchronous AsyncResult hack cause there you need to
> handle the state yourself. Both being compatible I see it as a consistent
> usage of each API.
>
> 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>
>
> 2016-03-08 13:53 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>
>> FYI - more feedback from just another developer that happens to care a
>> great deal about EE.
>>
>> Begin forwarded message:
>>
>> *From:* Josh Juneau <juneau001 at gmail.com>
>> *Date:* March 8, 2016 at 7:41:56 AM EST
>> *To:* "users at javaee-spec.java.net" <users at javaee-spec.java.net>
>> *Subject:* *[javaee-spec users] Re: CompletableFuture Usage in the
>> Platfom vs CDI*
>> *Reply-To:* users at javaee-spec.java.net
>>
>> Reza-
>>
>> I am in agreement with you.  I agree that CompleteableFuture seems to
>> make more sense for asynchronous events than CompletionStage.  Given that
>> it is widely acceptable throughout the platform, and the naming aligns more
>> closely with asynchronous activity...I think CompleteableFuture would be a
>> more consistent and standardized choice.
>>
>> Thanks
>>
>> Josh Juneau
>> juneau001 at gmail.com
>> http://jj-blogger.blogspot.com
>> https://www.apress.com/index.php/author/author/view/id/1866
>>
>>
>> On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman <reza_rahman at lycos.com>
>> wrote:
>>
>>> The CDI EG is incorporating the concept of CompletableFuture into
>>> asynchronous events. Unfortunately for reasons I really don't see as good
>>> they are using it's superinterface CompletionStage instead of
>>> CompletableFuture.
>>>
>>> I think this is a big ease-of-use mistake as CompletableFuture is
>>> designed to be the end user high level gateway API while CompletionStage is
>>> mostly as SPI intended for framework writers.
>>>
>>> Given that the CompletableFuture concept is pretty widely applicable
>>> throughout the platform I think there is a need for consistency, oversight
>>> and guidance from the platform expert group. Otherwise I fear less than
>>> ideal ad-hoc decisions might be made in this case for CDI and possibly
>>> others down the line.
>>>
>>> What do you think?
>>
>>
>>
>> _______________________________________________
>> 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/20160308/018f8816/attachment-0001.html