RFR 8020921 <was> Re: CompletableFuture updates and CompletionStage
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