RFR 8005696: Add CompletableFuture - JEP 155 (original) (raw)

Doug Lea dl at cs.oswego.edu
Fri Mar 15 12:00:43 UTC 2013

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

More information about the core-libs-dev mailing list