The specdiff is very helpful. It was much easier to see that the
cross-method links from whenComplete to handle could be improved, so
we'll change (modulo reflow)
--- src/main/java/util/concurrent/CompletionStage.java 24 Jan 2016
21:22:16 -0000 1.37
+++ src/main/java/util/concurrent/CompletionStage.java 10 Feb 2016
23:29:49 -0000
@@ -736,7 +736,7 @@
* {@code null} if none) of this stage as arguments. The returned
* stage is completed when the action returns.
*
- * <p>Unlike method {@link #handle}, this method is not designed
+ * <p>Unlike method {@link #handle handle}, this method is not designed
* to translate completion outcomes, so the supplied action should
* not throw an exception. However, if it does, the following
* rules apply: if this stage completed normally but the supplied
@@ -762,7 +762,7 @@
* if none) of this stage as arguments. The returned stage is completed
* when the action returns.
*
- * <p>Unlike method {@link #handle}, this method is not designed
+ * <p>Unlike method {@link #handleAsync(BiFunction) handleAsync},
this method is not designed
* to translate completion outcomes, so the supplied action should
* not throw an exception. However, if it does, the following
* rules apply: If this stage completed normally but the supplied
@@ -788,7 +788,7 @@
* if none) of this stage as arguments. The returned stage is completed
* when the action returns.
*
- * <p>Unlike method {@link #handle}, this method is not designed
+ * <p>Unlike method {@link #handleAsync(BiFunction,Executor)
handleAsync}, this method is not designed
* to translate completion outcomes, so the supplied action should
* not throw an exception. However, if it does, the following
* rules apply: If this stage completed normally but the supplied
On Wed, Feb 10, 2016 at 2:51 PM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>
> On 10 Feb 2016, at 15:53, Martin Buchholz <marti...@google.com> wrote:
>
> Thanks for creating the specdiff, but ... it looks reversed; the green
> is the old and the red is the new!
>
>
> D’oh, of course. Updated in-place.
>
> http://cr.openjdk.java.net/~chegar/jsr166-jdk9-integration-CompletableFuture/CompletionStage.html
>
> Sorry for our "endless fiddling"; we do have future changes in mind,
> but no spec changes.
>
>
> No problem.
>
> -Chris.
>
> On Wed, Feb 10, 2016 at 2:50 AM, Chris Hegarty <chris.hega...@oracle.com>
> wrote:
>
> On 02/02/16 15:23, Martin Buchholz wrote:
>
>
> On Tue, Feb 2, 2016 at 6:37 AM, Chris Hegarty <chris.hega...@oracle.com>
> wrote:
>
>
>
> On 1 Feb 2016, at 18:45, Martin Buchholz <marti...@google.com> wrote:
>
> After much debate on what to do when CompleteableFuture.whenComplete
> encounters an exception in both the source and the action, we chose
> what was acceptable to the most people - add the action's exception to
> the source exception as a suppressed exception. And added usage
> guidelines. And gave handle "top billing" over whenComplete.
>
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
>
>
>
> This all looks fine to me.
>
> So I assume you only need a small CCC request for CompletionStage, right?
> Everything else is implementation.
>
>
>
> If you squint you might argue that CompletionStage's contract hasn't
> actually changed,
> but yeah, go ahead and do a CCC for CompletionStage. Publishing a
> specdiff would be nice - method reordering (for "top billing") has
> made the diffs harder to review. Thanks.
>
>
>
> Here are the specdiffs that will be used for the CCC, unless there are
> any last minute changes.
>
> http://cr.openjdk.java.net/~chegar/jsr166-jdk9-integration-CompletableFuture/CompletionStage.html
>
> -Chris.
>
>
