RFR 8005696: Add CompletableFuture - JEP 155

[Doug Lea]

On 03/14/13 23:25, Martin Buchholz wrote:
> Doing a mini-audit of these methods, here is a change to what seems to be the
> intent:

Yes, thanks! This keeps the exception specs consistent across similar
methods.

-Doug


>
> Index: ./java/util/concurrent/CompletableFuture.java
> ===================================================================
> RCS file:
> /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CompletableFuture.java,v
> retrieving revision 1.55
> diff -u -U 7 -r1.55 CompletableFuture.java
> --- ./java/util/concurrent/CompletableFuture.java16 Feb 2013 21:25:55 -00001.55
> +++ ./java/util/concurrent/CompletableFuture.java15 Mar 2013 03:23:26 -0000
> @@ -1683,35 +1683,35 @@
>        */
>       public CompletableFuture<Void> thenAccept(Consumer<? super T> block) {
>           return doThenAccept(block, null);
>       }
>       /**
>        * Creates and returns a CompletableFuture that is asynchronously
> -     * completed using the {@link ForkJoinPool#commonPool()} with this
> -     * CompletableFuture's result when it completes.  If this
> -     * CompletableFuture completes exceptionally, then the returned
> -     * CompletableFuture also does so, with a CompletionException holding
> -     * this exception as its cause.
> +     * completed after performing the given action using the {@link
> +     * ForkJoinPool#commonPool()} with this CompletableFuture's result
> +     * when it completes.  If this CompletableFuture completes
> +     * exceptionally, then the returned CompletableFuture also does so,
> +     * with a CompletionException holding this exception as its cause.
>        *
>        * @param block the action to perform before completing the
>        * returned CompletableFuture
>        * @return the new CompletableFuture
>        */
>       public CompletableFuture<Void> thenAcceptAsync(Consumer<? super T> block) {
>           return doThenAccept(block, ForkJoinPool.commonPool());
>       }
>       /**
>        * Creates and returns a CompletableFuture that is asynchronously
> -     * completed using the given executor with this
> -     * CompletableFuture's result when it completes.  If this
> -     * CompletableFuture completes exceptionally, then the returned
> -     * CompletableFuture also does so, with a CompletionException holding
> -     * this exception as its cause.
> +     * completed after performing the given action using the given
> +     * executor with this CompletableFuture's result when it completes.
> +     * If this CompletableFuture completes exceptionally, then the
> +     * returned CompletableFuture also does so, with a CompletionException
> +     * holding this exception as its cause.
>        *
>        * @param block the action to perform before completing the
>        * returned CompletableFuture
>        * @param executor the executor to use for asynchronous execution
>        * @return the new CompletableFuture
>        */
>       public CompletableFuture<Void> thenAcceptAsync(Consumer<? super T> block,
>
>
>
> On Thu, Mar 14, 2013 at 10:21 AM, Chris Hegarty <chris.hegarty at oracle.com
> <mailto:chris.hegarty at oracle.com>> wrote:
>
>     As part of JEP 155 (Concurrency Updates) we are proposing to add
>     CompletableFuture. A Future that may be explicitly completed (setting its
>     value and status), and may include dependent functions and actions that
>     trigger upon its completion.
>
>     Specdiff:
>
>     http://cr.openjdk.java.net/~__chegar/8005696/specdiff/java/__util/concurrent/package-__summary.html
>     <http://cr.openjdk.java.net/~chegar/8005696/specdiff/java/util/concurrent/package-summary.html>
>     Webrev:
>     http://cr.openjdk.java.net/~__chegar/8005696/webrev.00/__webrev/
>     <http://cr.openjdk.java.net/~chegar/8005696/webrev.00/webrev/>
>
>     CompletableFuture, as usual, is coming from Doug Lea, with assistance from
>     members of the former JCP JSR-166 Expert Group. I have already informally
>     reviewed this. This is an official call for review before finalizing the API
>     for inclusion in jdk8.
>
>     Note:
>        I still need to make some additions to the test for better coverage, but
>     these should not be a blocker for this review.
>
>     -Chris.
>
>