jextract fails to compile generated source

[sundararajan.athijegannathan at oracle.com]

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

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!

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?

"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

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