some thoughts on panama/jextract

[Samuel Audet]

If it's not Panama's job to do that, that's fine, but it needs to help
developers that uses that API to achieve that goal. Like Ty mentioned, it's
possible to do that with annotations. JavaCPP uses @Cast for that so we can
declare native functions in a portable fashion this way:

native void function(@Cast("size_t") long arg)

That works just as well with any typedef integer or template that wraps a
number. The same idea also works for any arbitrary data structure. How do
you recommend to do that with Panama? 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!

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.

Samuel

2020年1月8日(水) 20:15 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:

>
> On 08/01/2020 10:01, Samuel Audet wrote:
> > The Java API that gets created for all these platforms is exactly the
> > same, and it works exactly the same on all these platforms as well.
> > That's the kind of thing the Java community needs, in my opinion.
>
> I agree that, as a user, the best case is to just download some Maven
> artifact that gives me the library I want (if it exists!!!!!) - no
> matter which platform I'm on, and have a single javadoc to go through to
> learn the API.
>
> As we discussed on this thread, depending on the choices made by the
> API, this can sometimes be easy or hard to achieve. If a library creates
> portable type definitions, so that the layouts remain the same across
> platforms - or stays away from ambiguous types such as 'long' (which on
> Windows mean something else), then having a single API is indeed possible.
>
> If the API is really ill-behaved, there are choices to be made. One
> platform could have more functions than another platform - what do you
> do? Or, some struct layouts might be completely incompatible (e.g. a
> struct in a platform has 3 fields and in another has 4). If you have
> these issues, no matter what tool you use to generate the Java bindings
> - you _have_ to make choices about what to do, and how to paper over the
> differences.
>
> It is not Panama's job to tell you how to do that (paper over the
> differences) - I can imagine frameworks much more sophisticated (and
> higher level) applying various heuristics in order to try and compress
> all the extracted bindings into a uniform API.
>
> Maurizio
>
>