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 ?
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.
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.
-Chris.
On 24/07/2013 10:22, Paul Sandoz wrote:
On Jul 11, 2013, at 12:51 PM, Paul Sandoz<paul.san...@oracle.com> wrote:
Hi,
Doug's explanation provides an excellent hook to hang the RFR off:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8020291-completion-stage/specdiff/overview-summary.html
http://cr.openjdk.java.net/~psandoz/tl/JDK-8020291-completion-stage/webrev/
Any takers for reviewing?
Paul.
