Closed
Description
openedon Feb 14, 2023
I think it's worth having this conversation even just to keep track of the reasoning behind the decisions.
When I looked at the codebase, at first, I was pretty impressed by the fact that we are using async calls everywhere for Java.
This is a subject pretty much full of nuances in Java land as far as I know it.
Let's try to summarize a few key points:
CompletableFuture
API is not great and doesn't play well with most of the rest of the standard library, also, using it makes the code much much harder to understand and follow (e.g. we miss anasync
/await
construct)- Reactive programming has become quite popular in Java, and exposing a
CompletableFuture
interface is going to play nicely with all the frameworks adopting this paradigm (Akka, Vert-X etc. etc.) - Most of the libraries around are exposing still a blocking API(e.g. OkHttp), and, wrapping every call in
CompletableFuture
s might not be the ideal solution given the number of options that comes (scheduling on which Thread Pool? Keep separated IO blocking operations from in-process computing etc. etc.) - "Idiomatic" Java 8 code (as per Android compatibility) is not using the async API and it doesn't play nicely with imperative and blocking code
- Project Loom is coming with the promise to enable blocking idioms to easily work in contexts with concurrency and parallelism (since here we are keeping compatibility with Android I'm not sure about timelines here)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Assignees
Type
Projects
Status
Done ✔️