State of foreign function support

[Maurizio Cimadamore]

On 29/07/2020 19:45, Ty Young wrote:
>
> 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.
These are good ideas - the API is not 100% set in stone yet and it needs 
a round of polishing - both on signatures and javadoc.
>
>
> 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.

I hear you - it is a bit inconsistent with all the other various lookup 
functionalities we have around the JDK though - but we'll consider it.

Thanks
Maurizio

>
>
> Hopefully these are pretty reasonably suggestions.
>