RFR 8020921 <was> Re: CompletableFuture updates and CompletionStage

Paul Sandoz paul.sandoz at oracle.com
Wed Jul 24 12:37:08 UTC 2013

On Jul 24, 2013, at 12:04 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> Hi Paul, Doug,
> I am happy to be considered as a reviewer for this change.


> I think the separation of policies and execution mechanisms from the fluent completion-style capabilities is nice.
> Some minor comments/questions:
> 1) Should CS.toCompletableFuture declare UnsupportedOperationException
>   in its @throws ?

What is the convention for declaring runtime exceptions? I notice Iterator.remove does not declare runtime exceptions.

In fact it might make sense for this method to be a default implementation throwing UnsupportedOperationException, although the chances of this interface being wildly implemented compared to Iterator is very rare so that does not seem a terribly important thing to do.

> 2) "All CompletionStage methods are implemented independently of other
>    public methods, so the behavior of one method is not impacted by
>    overrides of others in subclasses."
>    I guess this could be an implNote, but then it might not be as
>    conveniently placed.

That policy reads to me like a spec requirement on CF.

> 3) "Actions supplied for dependent completions of non-async methods may
>    be performed by the thread that completes the current
>    CompletableFuture, or by any other caller of these methods. "
>    Is "these methods" referring to other SC methods, or other CF
>    methods? It should be the latter, right.

I presume it is referring to the implementations of the non-async methods on SC.


More information about the core-libs-dev mailing list