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

Document why this isn't merged back into capnproto-java (yet?) #21

Open
Flowdalic opened this issue Dec 19, 2021 · 2 comments
Open

Document why this isn't merged back into capnproto-java (yet?) #21

Flowdalic opened this issue Dec 19, 2021 · 2 comments

Comments

@Flowdalic
Copy link

I am maybe missing something, but I wonder why this hasn't been merged back into capnproto-java. Is there a particular reason for that? Or is it planned? It sure would be great to have the answers to this questions documented in the project' README (or somewhere else).

@keturn
Copy link

keturn commented Dec 19, 2021

https://github.com/vaci/capnproto-java-rpc/blob/master/website/index.md#future-work provides some information on this, but I do not know if all of those things are necessary for the minimum viable product.

@vaci
Copy link
Owner

vaci commented Dec 27, 2021

Hi,

Thank you for your interest!

I would be very pleased for this RPC implementation to be merged into the mainline repository, but unfortunately I don't have have enough free time to contribute to the project at the moment, and this implementation is sufficient for my limited requirements.

The impact on the existing codebase is fairly minimal, and mostly involves adding a capability table member to various data structures, and extending the (C++) code generator.

There are a few issues that need to be addressed before the implementation could be considered production quality.

  • The code generator currently generates incorrect Java code for generic interfaces. This is fixable, but the generator is not particularly fun to extend. It might be sufficient to use AnyPointers in place of generic parameters as an intermediate solution.
  • The event loop implementation (i.e. RpcSystem::runOnce) is a hack, and a cleaner integration with CompletableFuture would be nice.
  • There are a couple of places where the implementation relied on CompletableFuture features that were only introduced in Java 17, and the changes to make the code build under Java 11 need work: 950ba82

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

No branches or pull requests

3 participants