[foreign] Panama EA - August 2019 edition

[Ty Young]

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?


- struct get methods are a bit janky. It would be nice if it was changed 
to something less odd than a dollar sign.


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


- Bindings are not true modules and therefor can't be used in jLink.


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


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


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.


Thanks.

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