Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow returning plain Futures by default #68

Open
A248 opened this issue Aug 11, 2023 · 1 comment
Open

Disallow returning plain Futures by default #68

A248 opened this issue Aug 11, 2023 · 1 comment

Comments

@A248
Copy link

A248 commented Aug 11, 2023

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 plain Future 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.

@astonbitecode
Copy link
Owner

Thanks for the proposal, I agree with what you say.

The reasoning behind trying to handle the plain Futures 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 Futures will be handled along with the Completable ones. Without opting-in, the simple Futures will not be handled and the async call from Rust will fail with a descriptive error message.

How does it sound @A248?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants