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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Reza Rahman
FYI - more feedback from just another developer that happens to care a great deal about EE.

Begin forwarded message:

From: Josh Juneau <[hidden email]>
Date: March 8, 2016 at 7:41:56 AM EST
To: "[hidden email]" <[hidden email]>
Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI
Reply-To: [hidden email]

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


On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman <[hidden email]> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
@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 <[hidden email]>:
FYI - more feedback from just another developer that happens to care a great deal about EE.

Begin forwarded message:

From: Josh Juneau <[hidden email]>
Date: March 8, 2016 at 7:41:56 AM EST
To: "[hidden email]" <[hidden email]>
Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI
Reply-To: [hidden email]

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


On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman <[hidden email]> 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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

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

Reza Rahman
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 <[hidden email]> 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 <[hidden email]>:
FYI - more feedback from just another developer that happens to care a great deal about EE.

Begin forwarded message:

From: Josh Juneau <[hidden email]>
Date: March 8, 2016 at 7:41:56 AM EST
To: "[hidden email]" <[hidden email]>
Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI
Reply-To: [hidden email]

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


On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman <[hidden email]> 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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau


2016-03-08 14:22 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
FYI - more feedback from just another developer that happens to care a great deal about EE.

Begin forwarded message:

From: Josh Juneau <[hidden email]>
Date: March 8, 2016 at 7:41:56 AM EST
To: "[hidden email]" <[hidden email]>
Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI
Reply-To: [hidden email]

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


On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

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

Reza Rahman
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 <[hidden email]> wrote:



2016-03-08 14:22 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
FYI - more feedback from just another developer that happens to care a great deal about EE.

Begin forwarded message:

From: Josh Juneau <[hidden email]>
Date: March 8, 2016 at 7:41:56 AM EST
To: "[hidden email]" <[hidden email]>
Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI
Reply-To: [hidden email]

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


On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
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 <[hidden email]>:
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 <[hidden email]> wrote:



2016-03-08 14:22 GMT+01:00 Reza Rahman <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
FYI - more feedback from just another developer that happens to care a great deal about EE.

Begin forwarded message:

From: Josh Juneau <[hidden email]>
Date: March 8, 2016 at 7:41:56 AM EST
To: "[hidden email]" <[hidden email]>
Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI
Reply-To: [hidden email]

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


On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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.