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