Re: CompletableFuture.cancel vs Future.cancel bug?

I agree that the Future.cancel javadoc should be improved to better 
distinguish the return value spec from the method description. It was 
not the intent to require the return value to be a CAS-like indication 
of whether the current invocation was responsible for cancellation. It 
is nice when it can do so (and some implementations do), but the 
intention for this high-level interface spec was to allow a wide range 
of implementations,. Perhaps it would have been better to define cancel 
as void, requiring a call to isCancelled to check. In other words...

On 8/20/20 3:06 PM, Sergi Vladykin via Concurrency-interest wrote:
>
> Here is the part with "typically":
>
>      * @return {@code false} if the task could not be cancelled,
>      * typically because it has already completed normally;
>      * {@code true} otherwise
>
> I read it as "usually it is impossible to cancel the task because it 
> has already been completed normally, but there are other reasons: for 
> example it has already been completed exceptionally or cancelled".
The case left out here is "already cancelled", which can go either way.
>
> And I've already cited the beginning of that javadoc which explicitly 
> states that the attempt WILL fail if the task has been cancelled:
>
>      * Attempts to cancel execution of this task.  This attempt will
>      * fail if the task has already completed, has already been cancelled,
>      * or could not be cancelled for some other reason.
> I see no room for wiggling here.

"The attempt" is not a description of return value. Sorry for the confusion.

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest