Providing your own SymbolLookup / ServiceLoader for SymbolLookup

[Maurizio Cimadamore]

On 20/08/2024 23:42, some-java-user-99206970363698485155 at vodafonemail.de 
wrote:

> Hello,
>
> first of all thank you for your work on the FFM API and jextract! It 
> is really great that interoperability with native libraries becomes 
> easier.
>
> One issue I currently have with jextract is that none of its 
> `--library` or `--use-system-load-library` options seem to offer a way 
> for users to provide their own SymbolLookup. Why is this an issue?
> - The header class generated by jextract and possibly additional 
> bindings classes might be generated by a third-party project, so you 
> cannot easily modify the source code to change the SymbolLookup 
> creation (unless you want to fork that project).
> - For convenience Java projects often bundle native libraries, extract 
> them to a temporary file and then load them, for example even JavaFX 
> does this (see its `NativeLibLoader` class). This avoids requiring 
> users to configure `java.library.path`. There are probably advantages 
> and disadvantages with this approach, but nonetheless it would be 
> useful if developers had the choice, by providing their own 
> SymbolLookup and specifying the path of the library.
> - `SymbolLookup#libraryLookup` seems to be currently the only API 
> which allows manually unloading the library (by closing the `Arena`). 
> All other approaches either keep the library loaded until JVM exit, or 
> until the classloader is garbage collected which might be JVM exit as 
> well (?).
>   Especially on Windows this is a problem because it prevents the 
> deletion of the file while the library is loaded, so 
> `File#deleteOnExit` or similar won't have any effect.

Well, jextract generates code. If you have your own lookup, jextract 
cannot know what code to generate. One option would be to use a service 
loader (as you suggest), but this would require a jextract runtime 
library, which we don’t want (unless the service is in the JDK, which we 
also don’t want).

An option that often works in these cases is to NOT use any —library 
option. Jextract will generate nothing, but will use the loader lookup. 
So you are free to “influence” what’s in the loader lookup as you wish 
(e.g. by calling System::loadLibrary). This tend to work for native 
libraries distributed via maven inside jars (but with the limitation 
that you cannot unload).

Another option, which we are considering for the long term, is to change 
the bindings so that jextract will generate a “default” instantiation of 
a binding, but then you can also use the provided constructor to specify 
your own lookup. Something like this:

|class OpenGL { int GL_VERSION(); // this is an _instance method_ ... // 
other bindings OpenGL(SymbolLookup lookup) { ... } static final OpenGL 
LIB = new OpenGL(/* lookup selected from command line option */); } |

This gives you bindings that are “ready to use”, pretty much as today - 
but in addition, you can create your own “LIB” instance with whatever 
lookup you want. I believe this is where we want to go (and this doesn’t 
suffer from the pesky problems you described with the service provider 
interface having to decide in which arena to work).

Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20240821/76f6bd38/attachment.htm>