[foreign] RFR 8212560 : jextract should generate a static forwarder class

[Maurizio Cimadamore]

On 18/10/2018 14:49, Samuel Audet wrote:
> If jextract could have 2 mode of operations, one where it parses the 
> header files, and another one, where it can generate the annotations 
> at runtime

Still not following; jextract is a static component - how can it 
generate annotations at runtime?

Seems to me that your original comment was on being able to use a 
simpler system of annotations - as in:

         @SizeT long tv_sec();

Which might be a valid argument/question, but it has little to do with 
jextract and everything to do with the binder. The reason why 
annotations include layouts is that, in general cases, things are messy 
- there's padding for one, that is not captured well by annotations; 
also you can't rely on the order in which methods are declared when 
using reflection, as at runtime that order is not guaranteed.

jextract is a tool, which takes an header and generates a set of 
interfaces with some annotations (which the binder likes), all bundled 
in a jar. That's what the tool does and (apart from some hiccups we are 
aware of) it does its job pretty well, as we have been able to extract a 
considerable set of non trivial libraries (such as TensorFlow, OpenGL, 
OpenCL, Clang, Python, ...). Extracting layouts from headers _is_ 
precise and does not require any guessing (as you seem to imply). The 
problem with function-like macros, or with other compile-time-only 
entities such as inline C++ methods, templates, overloaded methods is 
that these features are not reified in the system ABI - e.g. the shared 
library knows nothing e.g. about function-like macros - and as a result 
you have no native entry point to work with when it comes to Panama.

We have already shared some ideas on how to cover that space [1], so 
please refer to that. Again, I have a feeling that another RFR has been 
hi-jacked into a big design goals re-discussion, so please, if needed 
create a new thread.

[1] - 
http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001537.html

Maurizio