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

[Samuel Audet]

On 10/19/2018 01:03 PM, Maurizio Cimadamore wrote:
> 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.

The order is not guaranteed because of the current specifications of the 
JDK, but that's something you (the JDK developers) could improve, such 
as with the values types of Valhalla. BTW, is there a way to map layouts 
to value types and vice versa? I think that would go a long way in 
solving this kind of issue. If value types are not the answer, then why 
not do something about it anyway?

Another way could be to let the binder access the header files, as with 
the Substrate VM. That's an approach Panama could use as well, but I 
find it much more natural to map value types to layouts. Then we don't 
need to mess at all with the C language.

> 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.

No, there is still a lot of guess work involved. I guess I'll have to 
leave you guys go at it some more and fail before you listen further to 
what I have to say :(

> 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.

Well, I'm very glad that you take the time to listen to some of what I 
say, unlike John who basically ignored everything I said a few years 
back, but I feel we've come to a limit in our ability to discuss, so I 
think I'll leave things like they are for now. When you have some 
numbers to provide, then we can discuss. I'll refrain from hijacking any 
further thread until that time :) Sorry about that

Samuel