jextract fails to compile generated source

[Ty Young]

On 6/29/20 4:08 AM, sundararajan.athijegannathan at oracle.com wrote:
> Hi,
>
> From your example, I see that jextract generates non-identifier name. 
> That's a bug. I'll file one.
>
> Yes, even with the source "constants" is a .class file because it uses 
> constant dynamic ("condy") and so no source equivalent for the same. 
> But user should be able to compile the rest of the sources by proper 
> classpath (the bug you've hit is orthogonal).


Will there be the ability to dump layout information to a file added 
anytime soon? I understand plugins are a thing, but I really feel like 
there is a good use case where people just want to get layout 
information and nothing else and it should be supported by default.


>
> We no longer generate lot of header file classes. One header file 
> class is lot easier to work with - or in the old model user would have 
> to know which C header file a particular declaration came from!


I don't know how getting 1000+ IDE code prompts when using IDE 
auto-completion is a "lot easier to work with" or  how the searchability 
of a C decleration from Java matters either, you're probably going to 
need to find the header file anyway so you can read documentation and 
comments. I do, anyway, but maybe that's just me.


Agree to disagree I guess. jextract isn't a requirement for me. I'm just 
using it now to get layout information half because I'm lazy and half 
because I want to make sure it's right. Just saying that, in my opinion, 
the current way things are generated won't make for a good user 
experience. I know it wasn't when I first tried out the new jextract in 
Netbeans.


>
> You may want to take a look at samples with the new jextract:
>
> https://github.com/sundararajana/panama-jextract-samples
>
> "It also makes an otherwise already potentially long and hard to read 
> binding generation even harder to read and understand, from a source 
> code readability perspective."
>
> Please elaborate exactly which part you find it hard to read?


It's just a really huge file with everything from the library thrown 
into it and there is zero indication as to where any of the static 
methods come from. Is function Foo from nvidia-xconfig or is it from 
some other random header file? There is no way to tell. Could 
annotations be added maybe?


>
> "The generation of a dozen helper classes is also a bit of an issue, 
> IMO, but I've raised my issues before so I'm not going to go into 
> those again."
>
> I think you refer Cint, Clong, Cchar etc. These helpers do simplify 
> accessing platform specific int, long char etc. Without these user 
> would have to
>
> deal with VarHandles directly (to pass/read C int[] for eg). Again, 
> please take a look at samples how these are used. In particular linear 
> algebra


I guess my issue with it is that you're generating a pseudo high-level 
API for every jextract binding. If someone uses it to generate 5 
bindings and uses all of them in a single project, assuming they 
separate the bindings, they'd have 5 Cint classes. Every <TYPE>support 
class also creates its own constant VarHandle and such too, taking up 
more memory(even if really small amounts)


Maybe jextract just isn't for me, which is fine. Again, I'm just using 
it out of laziness and to make sure my hand-made bindings actually work 
correctly.


>
> samples.
>
> -Sundar
>
>
> On 29/06/20 1:41 am, Ty Young wrote:
>> Hi,
>>
>>
>> I attempted to use jextract to get the struct layout of 
>> "nvidia-xconfig.h" from:
>>
>>
>> https://github.com/NVIDIA/nvidia-xconfig
>>
>>
>> using:
>>
>>
>> jextract nvidia-xconfig.h
>>
>>
>> by accident(forgot you need --source at first) and it failed with:
>>
>>
>> https://pastebin.com/KgBpAAtd
>>
>>
>> Once I specified --source, the output I got wasn't expected either. 
>> The $constants file was a .class despite --source specified. I'm not 
>> seeing where the layouts are defined in the nvidia-xconfig_h.java 
>> file, so I'm assuming the layout information is stored there, unless 
>> I missed them.
>>
>>
>> This is the first time since I initially tried using the new jextract 
>> and I have to say I really don't like how it combined multiple native 
>> header bindings into a single file.
>>
>>
>> Looking at nvidia-xconfig_h.java I have no idea where half of the 
>> static methods are coming from. It's extremely confusing seeing 
>> dependency header static methods casually thrown into a single file 
>> and the end user using the bindings is going to be very confused when 
>> they refer to the native header file for information only to find 
>> nothing since it's the wrong one.
>>
>>
>> It also makes an otherwise already potentially long and hard to read 
>> binding generation even harder to read and understand, from a source 
>> code readability perspective. If I wanted to use a jextract source 
>> code binding as a guide on how I'd generate my own hand-made bindings 
>> I'd have to easily go through 2k lines of code.
>>
>>
>> The generation of a dozen helper classes is also a bit of an issue, 
>> IMO, but I've raised my issues before so I'm not going to go into 
>> those again.
>>
>>
>> A question though: is there any advantages to using MethodHandle's 
>> invokeExact vs. invoke? I randomly came across a StackOverflow(IIRC) 
>> post awhile ago where supposedly invokeExact is marginally faster but 
>> I'm not sure how true that is. I don't do benchmarking but if it's a 
>> noticeable speedup I'll change my code to use it.
>>