Capnproto RPC for Java - progress

[Vaci]

Hi,

I now have a reasonably complete implementation of Capnproto RPC in pure Java.

The major features still missing are:

• file descriptor passing
• generics

The former is not likely to find support any time soon in Java's asynchronous socket library. The latter is hopefully 'just' extensions to the compiler.

Streams are recognised, but just fall back to non-streaming implementations.

Cancellation and disconnection still need some work.

I have slight regrets about using Java's CompletableFuture framework - eager completion of promises without any guarantee of ordering made for some interesting debugging - but it is at least a "standard" API. I would like to find a better solution for running the client side message loop as just waiting for promises to complete isn't sufficient.

I have yet do do any serious stress or performance testing; so far the implementation has been 'good enough' for my requirements.

I suspect there are still plenty of bugs, so if anybody is interested in finding them, please check it out:

https://github.com/vaci/capnproto-java-rpc

cheers,

Vaci

[Ian Denhardt]

Quoting Vaci (2020-11-26 11:54:48)

> Hi,
>
> I now have a reasonably complete implementation of Capnproto RPC in
> pure Java.

Nice!

>
> The major features still missing are:
>

> * file descriptor passing

Fwiw, you're in good company here -- I think the C++ implementation is
the only one that supports this (most others were written before this
existed, and haven't been updated to include it afaik). Same thing for
the streaming stuff.

-Ian

[Vaci]

There is at least one Java implementation of Unix sockets out there (https://github.com/AgNO3/junixsocket) that might be usable via an adapter mechanism. The code to handle file descriptors is all in place, but dormant for now.

[Kenton Varda]

This is great!

Out of curiosity, do you have a specific use case you're building for?

Do you have any RPC-specific documentation or examples yet?

I notice this is implemented as a fork of the existing capnproto-java. Did you have to make changes to the existing code? Is the API compatible?

I agree with Ian that FD passing probably isn't going to be important to Java users, so I wouldn't bother too much with it.

+David Renshaw, have you looked at this at all?

-Kenton

--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/e7973e0b-109b-44d3-9e90-0a2753439be3n%40googlegroups.com.

[Vaci]

My main interest is that it's been hard to make a case for Capnproto in a multi-language development environment, when the majority language is Java. I must confess that I am mostly a C++ developer, and haven't done any serious Java work for years, and this looked like a nicely sized problem to re-acquaint myself with the language.

 

No docs yet, but I have a bunch of RPC test cases, and the Calculator example could be added to the examples project. I'm at an impass currently, deciding whether to dump CompletableFutures altogether and replace with a home-grown futures library, which would change the API significantly. My implementation doesn't use the concurrent features of CompletableFutures (except for socket calls), so there's a bunch of unnecessary thread-safety operations going on, and also Capnproto is picky about the order in which events complete, whereas CompletableFutures very much take a YOLO approach to completion order. That made made, for example, QueuedClient tricky to get right and I'm still not entirely confident about it.

Changes to the existing code have, fortunately, been fairly limited. The most intrusive change was to keep track of a cap-table context in builders, readers and arenas, but I think I've achieved that without affecting the existing API. AnyPointers have gained a method or two. Otherwise pretty much everything else is new and separate code - the RPC implementation itself is a separate library,  as it should be! On the compiler side, it's mostly been a case of rendering the interface types and adding pipelines, so existing code hasn't been touched outside of the previously unimplemented switch branches. That may be less true once generics enter the picture.

The new code probably requires a recent (14+?) Java compiler version.

cheers,

Vaci

[Kenton Varda]

Awesome, I'm very glad to hear you've been paying attention to ordering -- it's tricky to get right but turns out to be very important.

I'm hoping David weighs in at some point and we can decide whether it makes sense to merge this back into the main repo.

-Kenton

--

You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/6e4ebe50-1dc5-450d-bf05-6df063fd1a6dn%40googlegroups.com.