some thoughts on panama/jextract

[Maurizio Cimadamore]

On 06/01/2020 06:57, Michael Zucchi wrote:
> Well for C libclang is constrained by the ABI for the platform but I 
> was thinking of other things like pointer sizes or exposed platform 
> pieces (or even compile options).  Although a well designed api will 
> abstract the latter they don't all do it.  I use jmods already so that 
> works for the binary part, it's the source-part i was worried about 
> because as soon as something isn't auto-generated, it's manual work 
> and i'm lazy. 

This is a problem we're acutely aware of. The hope is that most 
libraries will make _some_ effort when it comes to portability, so that 
you won't need completely different bindings on each new platform. In 
reality though, header files are messy, and nothing prevents you from 
having platform-specific functions, and/or platform-dependent struct 
layouts. If a library does that, and assuming the differences are big 
enough, the only retreat might be to run jextract on all the relevant 
platforms - and then have some higher level, platform-agnostic bindings 
which, based on the platform, will dispatch to the right set of bindings.

I think the core of the issue is there with JNI too - e.g. imagine you 
have a library with an header that defines the following function:

void foo(long);

How do you model this as a native method in Java? Two options:

native void foo(int)

native void foo(long)

The former is the safest - in the sense that it will work correctly on 
all platforms (e.g. even on Windows, where longs are 32 bits). The 
latter will take advantage of the extra 32 bits, but will misbehave on 
Windows.

The main point I'm getting at here is that there is no "right" choice 
here, and even less so a "mechanically derivable" one. Even advanced 
multi-platform supports, such as the one provided by Kotlin [1] cannot 
really deal with signature changes across platforms - although the 
Kotlin approach admittedly would help when it comes to deal with 
platform-dependent layout constants.

[1] - 
https://kotlinlang.org/docs/reference/platform-specific-declarations.html

Maurizio