Custom Executor Injection

[vasapower]

I think you really did a fantastic job.

According to you, Is it possibile to inject, somehow, a custom Executor to let the generated CompletableFutures asynchronously run into a specific Context (in my case, Vert.x)?

If a lib verticalization is needed, what point of the source do you suggest to edit?

[DanielSperry]

That's a long postponed feature.
What to change depends on how you want it to look like from the user's perspective:

• Extra parameter to the await call? See Transformer.transformAwait. I think this is the best alternative.

     await(methodThatReturnCompletableFuture, executor); 
  

• Some static static setting?
• Extra parameter to the async method definition? Transformer.transformAsyncMethod. You might need this to pass a executor down to the awaits if you'd like it not to be explicit.

     @async CompletableFuture<String> someMethod(int a, int b, @AsyncExecutor executor)
  

• An annotated field or method in the class that calls await? Means that that field/method would be read by the instrumented method and passed as parameter to the .except and .whenComplete calls.
• Use the context in orbit.Task which can flow between threads and uses ThreadLocals. Transformer.transformAsyncMethod. See next item.
• Since the async methods schedule their listeners in futures returned by some other function, then, you could just make sure those futures only return a CompletableFuture implementation which by default uses a certain executor instance for all .then* and similar methods. So even after a chain of .thenSomething methods you'd still be using the initial executor. Orbit.Task was originally designed to to this.

I'll just ask you to be mindful not to add any new external compile or runtime dependency to ea-async.

[lukehutch]

I had the same question, and then I found this, which might solve the problem for Vert.x at least, although it sets up a new fork-join pool rather than using Vert.x's thread pool:

https://github.com/cescoffier/vertx-completable-future

There might be some parts of that codebase that could be added directly to EA Async to enable async/await on top of a Future-based or callback-based API.

[JoeHegarty]

We're certainly open to any PRs etc that support additional functionality such as this, but we have no plans to add this to the library ourselves at this time.