State of foreign function support

[Ty Young]

On 7/28/20 2:02 PM, Maurizio Cimadamore wrote:
> Hi,
> as promised, here's the document capturing the status of the Panama 
> foreign function support:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/ffi.html
>
> Cheers
> Maurizio
>

Meant to ask this a long time ago(sorry!), but I'd like to point out two 
(hopefully reasonable) things that should, IMO, be changed and/or added.


The first is LibraryLookup.ofPath. Currently, despite its name, does not 
accept a Path but a String instead. This is less than ideal for 3 reasons:


1. It's a naming/type mismatch.


2. The static method has a not documented requirement of an *absolute* 
String path. The Path class has the ability to check for and convert 
relative pathing to absolute paths, so a user does not need to concern 
themselves with being 100% exact.


3. Anyone using this absolute path static method is probably going to 
want to check if the library exists in the first place or if it's a 
symbolic link.  By using a Path over a String, Files.exists(<PATH>) 
could be used instead.


Second is with symbol accessing. Currently if a symbol lookup fails for 
a function, it throws a runtime exception. It would be nice if Optional 
was used instead, IMO. For some libraries, such as NVML, non-critical 
functions are added which cannot be reliably depended on due to slightly 
older driver package versions. An Option would overall be easier to deal 
with than runtime exceptions and it wouldn't be out-of-place given there 
is no guarantee that a symbol exists in a library. I realize this dips 
into the binding versioning rabbit hole, but I'd really like to see, if 
nothing else, a boolean to check if a symbol exists or not.


Hopefully these are pretty reasonably suggestions.