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

Tue Mar 8 08:45:46 EST 2016

For the same reason you don't expose setters in several cases I really
think the mutation of an immutable by design result shouldn't be exposed.
Code completion being the fastest documentation a user can see,
CompletionFuture tends to expose a wrong documentation of the proposed API.

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

> I think we've managed to devolve into unproductive bickering yet once
> again today or getting pretty close to it.
>
> No matter how many layers you pass a CompletableFuture through,
> implementation context will always make it clear to the end user it is a
> promise as far as they are concerned. They would have little reason to call
> complete(), get() or anything else that is provided as nice API design
> convenience in CompletableFuture.
>
> On Mar 8, 2016, at 8:27 AM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>
>
> 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.
>>
>
>
> _______________________________________________
> 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/e2e7fe03/attachment-0001.html 