A CompletableFuture is not related to the asynchronous action that may eventually complete it. Since (unlike FutureTask) this class has no direct control over the computation that causes it to be completed, cancellation is treated as just another form of exceptional completion. Method cancel has the same effect as completeExceptionally(new CancellationException()). There may not even … Read more
The factory methods using the standard functional interfaces aren’t helpful when you want to handle checked exceptions. When you insert code catching the exception into the lambda expression, you have the problem that the catch clause needs the CompletableFuture instance to set the exception while the factory method needs the Supplier, chicken-and-egg. You could use … Read more
OK, so there are 3 types of methods in CompletableFuture. For example: thenApply() thenApplyAsync(Function) (without an Executor) thenApplyAsync(Function, Executor) (with an Executor) The last one means that this action will execute in the Executor that you pass to it and it is the most obvious one. The second one means that the action is executed … Read more
By default CompletableFuture uses own ForkJoinPool.commonPool() (see CompletableFuture implementation). And this default pool creates only daemon threads, e.g. they won’t block the main application from terminating if they still alive. You have the following choices: Collect all CompletionStage to some array and then make java.util.concurrent.CompletableFuture#allOf().toCompletableFuture().join() – this will guarantee all the stages are completed before … Read more
Is this what you are looking for? askPong(“cause error”) .handle( (pong, ex) -> ex == null ? CompletableFuture.completedFuture(pong) : askPong(“Ping”) ).thenCompose(x -> x); Also, do not use the …Async methods unless you intend for the body of the supplied function to be executed asynchronously. So when you do something like .handleAsync((x, t) -> { if … Read more
I ran into something similar and came up with a solution that does not use reflection and seems to work well with JDK9-JDK11. Here is what the javadocs say: The parameters used to construct the common pool may be controlled by setting the following system properties: java.util.concurrent.ForkJoinPool.common.threadFactory – the class name of a ForkJoinPool.ForkJoinWorkerThreadFactory. The … Read more
Unlike Java 9 and later, Java 8 does not provide a static factory method for this scenario. The default constructor can be used instead: CompletableFuture<T> future = new CompletableFuture<>(); future.completeExceptionally(exception);
TL;DR: The ForkJoinPool uses daemon threads, whereas the ExecutorService is using non-daemon threads. The latter keep the JVM alive; the former do not. Also, the main thread is a non-daemon thread and when you block it waiting for the CompletableFuture to complete it remains alive (thus keeping the JVM alive). Daemon vs Non-Daemon Threads A … Read more
As @nullpointer points out, the documentation tells you what you need to know. However, the relevant text is surprisingly vague, and some of the comments (and answers) posted here seem to rely on assumptions that aren’t supported by the documentation. Thus, I think it’s worthwhile to pick it apart. Specifically, we should read this paragraph … Read more
Use CompletableFuture.allOf(…): static<T> CompletableFuture<List<T>> sequence(List<CompletableFuture<T>> com) { return CompletableFuture.allOf(com.toArray(new CompletableFuture<?>[0])) .thenApply(v -> com.stream() .map(CompletableFuture::join) .collect(Collectors.toList()) ); } A few comments on your implementation: Your use of .thenComposeAsync, .thenApplyAsync and .thenCombineAsync is likely not doing what you expect. These …Async methods run the function supplied to them in a separate thread. So, in your case, you … Read more