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.
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.
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.
On Mar 8, 2016, at 8:06 AM, Romain Manni-Bucau
<rmannibucau(a)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 | Blog | Github | LinkedIn | Tomitriber
2016-03-08 13:53 GMT+01:00 Reza Rahman <reza_rahman(a)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(a)gmail.com>
>> Date: March 8, 2016 at 7:41:56 AM EST
>> To: "users(a)javaee-spec.java.net" <users(a)javaee-spec.java.net>
>> Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI
>> Reply-To: users(a)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(a)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(a)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(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.