and ... webrev regenerated
On Wed, Feb 10, 2016 at 3:32 PM, Martin Buchholz <marti...@google.com> wrote:
> 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.
>>
>>
