RFR: jsr166 jdk9 integration wave 4

Chris Hegarty chris.hegarty at oracle.com
Thu Feb 11 10:56:16 UTC 2016


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.
>>> 
>>> 




More information about the core-libs-dev mailing list