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

Martin Buchholz martinrb at google.com
Tue Sep 27 03:42:32 UTC 2016

I don't remember what happened in 2005, but records say that I wrote:
"""Why not ......
- add to the spec of Future.cancel() a guarantee that subsequent calls
  to Future.isDone() always return true?
which led to the spec:
"""After this method returns, subsequent calls to isDone()
always return true."""

which does sort-of seem to contradict
"""This attempt will fail if ... or could not be cancelled for some other
although if you squint, you can interpret that as a requirement to throw
rather than return normally if ... could not be cancelled for some other
reason.  There's no @throws clause, but runtime exception specs are often

The Future javadoc is in need of some love, but perhaps there's little
progress because the troubles run deep.

On Sun, Sep 25, 2016 at 11:00 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> 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
> reason.
> On Sun, Sep 25, 2016 at 5:39 PM, Martin Buchholz <martinrb at google.com>
> wrote:
>> 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