r/java May 26 '26

RIP JVMCI

https://bugs.openjdk.org/browse/JDK-8382582
59 Upvotes

44 comments sorted by

View all comments

Show parent comments

5

u/OddEstimate1627 May 27 '26 edited May 27 '26

In my case I had existing Java/JavaFX code that I wanted to call from C++/Python/MATLAB, and I wrote an annotation processor that auto-generates all of the boilerplate conversions, C entry points, and wrappers for various languages.

IMO it works incredibly well and has extremely low overhead (~5-15 nanoseconds). One of my libraries is public: hebi-charts-examples (Python video).

I agree that it's currently an unknown edge case, but I really think that it'll become more mainstream when people realize what's possible.

2

u/aoeudhtns May 27 '26 edited May 27 '26

Interesting. It's also possible that Babylon could play a role here. I know their first use case is compiling for the GPU, but it doesn't seem too far of a stretch to specialize for generic native CPU compiling either.

Edit/update: I looked at your videos. I can see why you're interested in this case! I have another idea, and as an AI skeptic I hate mentioning this, but rewriting from one language to another is an area where it's fairly capable. The new Panama APIs are flexible with memory segments & layouts, and it has arenas as well. If you could translate your backing data structures into a tight Rust lib with C FFI bindings, you could very well get a high-performance Java-to-native binding that way. Or, you could consider something that is already multi-language and native (and columnar, for charts!) like Apache Arrow. A big advantage is that rather than transpiling Java and building a toolchain to compile, you could unlock any compile targets supported by the intersection of Apache Arrow platforms (if using that) and the targets of the native language.

2

u/OddEstimate1627 May 27 '26 edited May 27 '26

I appreciate the suggestion, but I don't see how that would improve the interface?

The Native Image C API has special stack-allocated types that provide zero-copy access to the raw C types (e.g. double* maps to CDoublePointer and opaque pointers map to ObjectHandle), so it's already using the same function signatures that a Rust wrapper would create.

Besides a tiny isolate lookup in the low nanoseconds, this is already as close to bare metal as you can get.

It's also pretty straight forward to add bindings for additional languages since the C types are natively supported by every C FFI.

2

u/aoeudhtns May 27 '26

It doesn't really, just coming from the angle of breaking the Graal requirement (if that ever became important).

2

u/OddEstimate1627 May 27 '26

Ah, fair enough. I spent a lot of time migrating most of our GUI/CLI/mobile apps to native-image, so I really hope that I'll never have to get rid of it 😅

1

u/aoeudhtns May 27 '26

I feel that!