There’s a bug in its documentation, but the CompletableFuture#thenCompose family of methods is the equivalent of a flatMap. Its declaration should also give you some clues public <U> CompletableFuture<U> thenCompose(Function<? super T,? extends CompletionStage<U>> fn) thenCompose takes the result of the receiver CompletableFuture (call it 1) and passes it to the Function you provide, which … Read more
The short answer is that the designers of Java try to eliminate the need for asynchronous methods instead of facilitating their use. According to Ron Pressler’s talk asynchronous programming using CompletableFuture causes three main problems. branching or looping over the results of asynchronous method calls is not possible stacktraces cannot be used to identify the … Read more
Functionally, the two approaches are more or less the same: you submit your tasks for execution; you don’t wait for the result. Technically, however, there are some subtle differences: In the second approach, you didn’t specify an executor, so it will use the common ForkJoinPool. You would have to pass an executor as second argument … Read more
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
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
When you call CompletableFuture#cancel, you only stop the downstream part of the chain. Upstream part, i. e. something that will eventually call complete(…) or completeExceptionally(…), doesn’t get any signal that the result is no more needed. What are those ‘upstream’ and ‘downstream’ things? Let’s consider the following code: CompletableFuture .supplyAsync(() -> “hello”) //1 .thenApply(s -> … Read more
CompletableFuture.runAsync(…) runs the Runnable in the forkJoin-Pool which is managed, while new Thread() creates a new thread which you have to manage. What does “is managed” mean, it’s pre-allocated and the threads are shared in the JVM. When the runnable is completed, the thread can be reused for other runnables. This makes better usage of … Read more
runAsync takes Runnable as input parameter and returns CompletableFuture<Void>, which means it does not return any result. CompletableFuture<Void> run = CompletableFuture.runAsync(()-> System.out.println(“hello”)); But suppyAsync takes Supplier as argument and returns the CompletableFuture<U> with result value, which means it does not take any input parameters but it returns result as output. CompletableFuture<String> supply = CompletableFuture.supplyAsync(() -> … Read more
Spring actually does all of the work behind the covers so you don’t have to create the CompletableFuture yourself. Basically, adding the @Async annotation is as if you called your original method (without the annotation) like: CompletableFuture<User> future = CompletableFuture.runAsync(() -> doFoo()); As for your second question, in order to feed it to an executor, … Read more
There is no âvs.â between the two â these are complementary technologies: CompletableFuture provides a convenient way to chain different stages of asynchronous computation â with more flexibility than Spring’s ListenableFuture; @Async provides convenient management of your background tasks and threads, with standard Spring configuration for your executor(s). But both can be combined (since Spring … Read more