Open A248 opened 1 year ago
Thanks for the proposal, I agree with what you say.
The reasoning behind trying to handle the plain Future
s was to allow using third party Java libraries from Rust, that return plain Future
and cannot be controlled/altered. Of course, in that case, anyone could implement their own wrapping Future
as j4rs
did, but I wanted to be easy for Rust devs that just want to call Java instead of write Java.
That being said, we could hide the simple Future
handling behind a Rust feature. If someone opts-in, the simple Future
s will be handled along with the Completable ones. Without opting-in, the simple Future
s will not be handled and the async
call from Rust will fail with a descriptive error message.
How does it sound @A248?
Suppose I have a large codebase using j4rs, with calls to jvm::invoke_async. I don't want to audit every single call site to ensure the returned future is
CompletableFuture
. You should consider disallowing the use of plainFuture
with async methods. Instead, you could expose the wrapper you wrote (J4rsPolledFuture
) and have callers use it as needed.This change would cohere with Rust's culture of paying for what you need explicitly. For example, dynamic dispatch must be enabled with
dyn
. Costs are not hidden from the programmer.