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.hega...@oracle.com> wrote: > > On 11 Feb 2016, at 01:37, Martin Buchholz <marti...@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 <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. >>>> >>>> >