[foreign] Panama EA - August 2019 edition

[Ty Young]

On 8/19/19 4:33 AM, sundararajan.athijegannathan at oracle.com wrote:
> Hi,
>
> Thanks for trying out the latest panama build. Inline responses below..
>
> On 19/08/19 1:02 am, Ty Young wrote:
>> Hi,
>>
>>
>> I've written a medium piece with some feedback[1]. In addition to the 
>> feedback in the article, there are some other additional things:
>>
>>
>> - No API doc even if the header includes documentation. Would it be 
>> possible to include the docs?
>>
>
> There are clang wrappers added for native doc comments.  (see also: 
> 8219967: Add clang document introspection API support in 
> jdk.internal.clang module). But we did find (Doxygen style) header 
> file comments in many files. If doxygen style comments are widespread, 
> jextract can use jdk.internal.clang module facility to read & put 
> those comments as javadoc comments.


Yep, they appear to be Doxygen style. NVML provides really in-depth 
documentation so it'd be really nice if it was included.


>
>
>>
>> - struct get methods are a bit janky. It would be nice if it was 
>> changed to something less odd than a dollar sign.
>
>
> That $ exists to avoid any possible clash with C/C++ names (as "$" is 
> not a legal identifier char there). Without that there is a 
> possibility native source name may clash with generated java names 
> (x_get is legal C/C++ identifier for eg).


Yet it's valid Java syntax. The more you know I guess.


>
>
>>
>>
>>
>> - No clear API for sending an enum type. It seems like Panama 
>> converts enum values from C/C++ to ints in Java which works if you 
>> create a corresponding Java enum but there are still functions that 
>> use enums as inputs.
>>
>
> C/C++ enums are mapped as ints and an annotation (which is not used 
> yet). C/C++ enums are more flexible/low level feature compared to Java 
> enums. For example, user can pass OR'ed enum values in C/C++ or even 
> an int value not specified in enum declaration! Java enums are 
> statically typed and more strict, mapping to Java enums will prevent 
> certain C/C++ enum use cases.


In my particular case it works since the enum int just represents an 
error message but... it's hard coded so it could break in the future. Is 
there any desire to try to fix this somehow?


>
>
>>
>> - Bindings are not true modules and therefor can't be used in jLink.
>>
>
> jextract can optionally generate a .jmod file instead of a .jar file. 
> The generated .jmod can then be jlink'ed. Please check the example here:
>
> https://hg.openjdk.java.net/panama/dev/raw-file/841483f2887f/doc/panama_foreign.html#jlinking-python-interpreter-in-your-jdk-mac-os 
>


That works for command line but Netbeans with Ant doesn't have an option 
for jLink.


Java 9 modules aren't exactly common as is and IDE/build system support 
isn't great either. Netbeans 11 for example still spits out a command 
line launch string that you can supposedly use to launch from command 
line from before Java 9 was even released still... which doesn't even 
work. The jmod format is even less common. In fact, besides Panama the 
only other project that I know of that builds jmods is JavaFX.


I understand including native libs in jars requires some workarounds and 
such, but that's already there and done with. Netbeans detects it as an 
automatic module. The only thing, as far as I can tell, is to include a 
module-info file. Could it be added?


>
>
>>
>> - Header includes in the generated jars can and do conflict with each 
>> other, which is a big problem if you use more than one binding at a 
>> time in a given module... sometimes a requirement if the software has 
>> multiple headers. It would be nice if these parts could just be 
>> included into one jar that contains multiple modules, with each 
>> module having the API of the corresponding header.
>
>
> Are you talking about multiple sessions of jextract'ed jars working 
> together? Or any other specific problem? Please explain.


Yes. Netbeans 11 complains that /usr/include(or wherever include is 
specified) is included from multiple modules if you import them into 
your project.


>
>
>>
>>
>> - I'm currently trying to create bindings for nvidia-settings(Linux 
>> Nvidia control panel, headers are in /usr/include/NVCtrl
>> ) but I keep getting either an unknown type "Bool" or "int64_t" for 
>> the nvctrllibs header depending on the arguments. I'm not sure which 
>> is closer to being more correct.... what is the correct Jextract for 
>> this?
>>
>
> Please provide details of your jextract command line and/or file a bug 
> with enough details.


Command is:


jextract -t org.nvidia.nvxctrl.nvxctrllib -L /usr/lib -lXNVCtrl 
--record-library-path /usr/include/NVCtrl/NVCtrlLib.h -o 
org.nvidia.nvxctrl.nvxctrllib.jar


which causes an unknown type error "Bool".

>
>
>>
>> All that said, how close is Panama? Is this foreign memory API going 
>> to stay going forward or will the project take a major shift? I'd 
>> *really* like to start putting this to use and am willing to make 
>> adjustment where needed if minor changes are made, but if the entire 
>> foreign API is scrapped it isn't worth it.
>
>
> Panama "memory access" ("memaccess" panama-dev branch) API is expected 
> to become stable first and then other parts of java.foreign later 
> ("foreign" branch stuff).


So the current java.foreign API as it is now could be scrapped in the 
future then? Not just additions/minor tweaks?





>
> Thanks
>
> -Sundar
>
>
>>
>>
>> Thanks.
>>
>> [1] 
>> https://www.reddit.com/r/java/comments/cr4z9u/messing_around_with_project_panama_2019_ea_and/?st=jzhd3vj5&sh=7994552f
>>
>>