[concurrency-interest] We need to add blocking methods to CompletionStage!

Joe Bowbeer joe.bowbeer at gmail.com
Mon Sep 26 06:00:44 UTC 2016

Cancellation: David, I can see your point. Future.cancel(true) was
discussed 8/27/05 and the extra text was added to make it clearer that the
state of Future after cancel is called is separate from the state of any
associated thread or task.

However, I think the added text corresponded too closely to the only
implementation of Future.cancel that existed at the time. Elsewhere the
spec tries to permit Future.cancel to fail for some reason other than
because the Future had already completed:

  "This attempt will fail if the task [...] could not be cancelled for some
other reason."

  "returns false if the task could not be cancelled, typically because it
has already completed normally"

Without the added text, my interpretation would be that if cancel returns
false and then isDone returns false, then cancel failed for some other

On Sun, Sep 25, 2016 at 5:39 PM, Martin Buchholz <martinrb at google.com>

> On Sun, Sep 25, 2016 at 2:22 PM, David Holmes <davidcholmes at aapt.net.au>
> wrote:
>> Yet we somehow added the clarification with no regard as to whether
>> cancel returned true or not. That seems wrong.
> Yikes!  I had always assumed that cancel was not permitted to leave the
> Future incomplete, perhaps influenced by the wording,
> """After this method returns, subsequent calls to {@link #isDone} will
> always return {@code true}."""
> It's much more in the spirit of Java to throw an exception if the future
> cannot be completed.  It's never come up, I think.

More information about the core-libs-dev mailing list