refactoring some Guava ListenableFUture to Java 8 CompletableFuture #7
Conversation
| public Optional<P> call() throws Exception { | ||
| return AbstractCachedProtocol.this.protocolCache.get(xWindow); | ||
| final CompletableFuture<Optional<P>> protocolFuture = CompletableFuture.supplyAsync(() -> { | ||
| return AbstractCachedProtocol.this.protocolCache.get(xWindow); |
There was a problem hiding this comment.
This does not guarantee that the task will be executed by the display executor and might give concurrency problems. Normally, in trinityshell, a POJO should only accessible by a single thread, as such, executors are single threaded and use queues to guarantee in order execution.
There was a problem hiding this comment.
Why did you say the task won't be executed by the display executor? The second argument of CompletableFuture.supplyAsync is the displayExecutor, so the provided task will be executed on the given displayExecutor.
|
To answer your questions: Do you have any plan to use Java 8? |
Hi, I'm doing research on new concurrent constructs in Java 8.
CompletableFuturein Java 8 has the same functionality as GuavaListenableFuture. ButCompletableFutureis much nicer because it comes together with Lambda expression in Java 8, and it is monadic, which makes the code more readable and cleaner. Also, it provides more ways to compose different tasks. Therefore, usingCompletableFutureinstead ofListenableFutureis better for future extension and maintenance of the code.I tried to refactoring some
ListenableFutureinstances intrinityshelltoCompletableFuture, so you can see the difference. You don't have to merge this pull request. I'm just wondering your opinion on this kind of refactoring (or migrating the code from Java 7 to Java 8). Do you think the refactoring is useful? Do you have any plan to use Java 8? Thanks.