RFR 8020921 <was> Re: CompletableFuture updates and CompletionStage

[Paul Sandoz]

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.

Thanks!


> 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.

Paul.