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