[foreign] Panama EA - August 2019 edition

[sundararajan.athijegannathan at oracle.com]

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.


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


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


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


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


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


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

Thanks

-Sundar


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