On Jul 24, 2013, at 12:04 PM, Chris Hegarty <chris.hega...@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.
