RFR: jsr166 jdk9 integration wave 4

[Martin Buchholz]

Finally integrated!  Nothing in the jsr166 queue at the moment.  (I'm
sure we'll fix that ...)

On Thu, Feb 11, 2016 at 2:56 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
> On 11 Feb 2016, at 01:37, Martin Buchholz <martinrb at google.com> wrote:
>
>> and ... webrev regenerated
>
> Thank you Martin, this is better.
>
> For completeness, the specdiff has been updated too:
>   http://cr.openjdk.java.net/~chegar/jsr166-jdk9-integration-CompletableFuture/CompletionStage.html
>
> -Chris.
>
>> On Wed, Feb 10, 2016 at 3:32 PM, Martin Buchholz <martinrb at 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.hegarty at oracle.com> wrote:
>>>>
>>>> On 10 Feb 2016, at 15:53, Martin Buchholz <martinrb at 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.hegarty at oracle.com>
>>>> wrote:
>>>>
>>>> On 02/02/16 15:23, Martin Buchholz wrote:
>>>>
>>>>
>>>> On Tue, Feb 2, 2016 at 6:37 AM, Chris Hegarty <chris.hegarty at oracle.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 1 Feb 2016, at 18:45, Martin Buchholz <martinrb at 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.
>>>>
>>>>
>