ffmbindings manual bindings to C++

[Lain Lain]

Hi Maurizio,

> But if some C++ method returns some A* -- what Java wrapper will we 
create? The problem here is that the choice of the wrapper (A vs. B) 
determines which set of methods will be invoked on that instance 
(because we're effectively bypassing C++'s virtual dispatch).

You are right. It seems this is caused due to C++ type erasure, which happens when C++ object is returned from C++ to Java.
Surprisingly, we did not come across this yet but this indeed very common issue. Possibly it can be addressed by parsing vtable and deciding which Java class (A or B) should be mapped back to the returned pointer.
We will document it for future investigations.

> But maybe, what you are 
trying to say is that, even with a simple PoC like the one I provided, 
it's possible to provide meaningful interop for at least /some/ C++ 
libraries (like eigen) ?

Yes. Sometimes creating JNI only to use single class from some C++ library sounds like too much work.

> IMHO, is not possible w/o having a C++ compiler on your 
side (inline functions are another issue).

Do we know if someone is working with C++ committee to include new keywords to C++ to help creating bindings? This is not only Java but many other languages could benefit from (Rust, ...)
For example, inline functions are mainly for optimization purposes. If compilers knew that inline function may be accessed from other languages they could, in addition to inlining it everywhere, preserve the original function so that bindings could access it. Something like keyword "extern" which we already have.

Regards,
 
 

Sent: Tuesday, March 04, 2025 at 12:21 PM
From: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
To: "Lain Lain" <lain at null.net>, jextract-dev at openjdk.org
Subject: Re: ffmbindings manual bindings to C++
Sorry for the formatting -- dunno what happened. Let me try again:
Hi Lain, this is some interesting work. When looking at the documentation, and at the examples provided, it is not clear to me how some features of C++ are supported. E.g. it seems to me that the bindings you create (esp. downcall handles) are completely static. That is, if you have B extends A, and both A and B define a virtual method, you will add a downcall handle in both classes, one for A and the other for B. Then you kind of rely on Java's (not C++'s !!) dynamic dispatch to make things work -- e.g. when you call A on an instance of B, the JVM will call B -- which will result in the correct C++ method being invoked. While this works for simple examples -- I'm a bit skeptical about the generality of this approach. Of course, as long as there's no multiple inheritance, and as long as all the C++ classes are created from the Java side of the fence, this might even work correctly.
But if some C++ method returns some A* -- what Java wrapper will we create? The problem here is that the choice of the wrapper (A vs. B) determines which set of methods will be invoked on that instance (because we're effectively bypassing C++'s virtual dispatch).
All things considered, this approach doesn't seem very different from the jextract PoC I shared -- in the sense that it models some C++ features to some degree without really providing full language interop support which, IMHO, is not possible w/o having a C++ compiler on your side (inline functions are another issue). But maybe, what you are trying to say is that, even with a simple PoC like the one I provided, it's possible to provide meaningful interop for at least some C++ libraries (like eigen) ?
Cheers Maurizio
 

On 04/03/2025 12:19, Maurizio Cimadamore wrote: 
Hi Lain, this is some interesting work. When looking at the documentation, and at the examples provided, it is not clear to me how some features of C++ are supported. E.g. it seems to me that the bindings you create (esp. downcall handles) are completely static. That is, if you have B extends A, and both A and B define a virtual method, you will add a downcall handle in both classes, one for A
and the other for B
. Then you kind of rely on Java's (not C++'s !!) dynamic dispatch to make things work -- e.g. when you call A
on an instance of B, the JVM will call B
-- which will result in the correct C++ method being invoked. While this works for simple examples -- I'm a bit skeptical about the generality of this approach. Of course, as long as there's no multiple inheritance, and as long as all the C++ classes are created from the Java side of the fence, this might even work correctly.
But if some C++ method returns some A* -- what Java wrapper will we create? The problem here is that the choice of the wrapper (A vs. B) determines which set of methods will be invoked on that instance (because we're effectively bypassing C++'s virtual dispatch).
All things considered, this approach doesn't seem very different from the jextract PoC I shared -- in the sense that it models some C++ features to some degree without really providing full language interop support which, IMHO, is not possible w/o having a C++ compiler on your side (inline functions are another issue). But maybe, what you are trying to say is that, even with a simple PoC like the one I provided, it's possible to provide meaningful interop for at least some C++ libraries (like eigen) ?
Cheers Maurizio
On 26/02/2025 02:13, Lain Lain wrote:

Hi,
We would like to present you ffmbindings project which helps to do manual bindings to C++ libraries from Java using FFM.
Currently it contains bindings to eigen C++ library but we are going to publish few more this month.
 
Source code: https://bitbucket.org/ffmbindings
Documentation: https://ffmbindings.onrender.com[https://ffmbindings.onrender.com]
 
Any feedback are welcome.
 
Thank you,
​