some thoughts on panama/jextract
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Jan 10 10:55:45 UTC 2020
On 10/01/2020 10:11, Samuel Audet wrote:
> To support all C/C++ compilers, it sounds like we would need to create
> dummy C/C++ programs that output the offsets and sizes of all the
> types we're interested in, somewhat like Autoconf does for types like
> "int" or "long", and generate the correct Panama calls and layouts out
> of that, in Java. Unless I'm missing something, even though it might
> not always be as efficient, doing it with JNI is easier and safer too
> because we get the C/C++ compiler to tell us if we're accessing memory
> correctly or not. So, in this case, JNI is both easier and safer than
> Panama!
You are probably referring to C++, as for C we don't have to guess, the
ABI tells us all the info we want pretty clearly.
>
> FWIW, I don't personally mind how ugly the API is, as long as it's
> fast. JNI is far from pretty, but I was able to create JavaCPP on top
> of it and it abstracts JNI away completely. That is to say, as long as
> you can make Panama fast, with zero overhead support for inline
> functions being pretty much the only feature that really matters, I
> will rebase JavaCPP on it, regardless of how easy-to-use or not it
> ends up being.
Glad to hear that!
Maurizio
More information about the panama-dev
mailing list