Loading native libraries from the classpath

[Maurizio Cimadamore]

Hi,
extracting libraries from jars into some temp folder, and loading from 
there is indeed a common use case.

That said, the logic to support this is rather fragile, it is not 
uncommon to run code in machines which don't have write access to /tmp - 
in which case such an approach would fail.

For this reasons, at the time being we have not provided explicit 
support for this mode of operation - we tend to view this more as a 
packaging problem, rather than an API one. For instance, when linking 
modules into a custom JDK image (using jlink) it is possible to bring in 
custom native libraries as well, which greatly simplifies 
running/testing an application (we use this technique for jextract 
itself [1]). But I understand that much of the toolchain (gradle, maven 
et. alias) are mostly written with jars in mind, so this might not be an 
option.

Maurizio

[1] - https://github.com/openjdk/jextract/blob/master/build.gradle#L97


On 15/01/2024 16:51, Jeffrey Yemin wrote:
> Hi,
>
> It seems fairly common for modules published to Maven Central to embed 
> native libraries in the .jar file itself, in order to avoid the 
> complications of applications having to install the native libraries 
> themselves.
>
> Some libraries (including one, 
> https://github.com/mongodb/libmongocrypt/tree/master/bindings/java/mongocrypt, 
> that I maintain for MongoDB) delegate the extraction of the 
> appropriate native library to JNA, while others that use JNI directly 
> (like https://github.com/xerial/snappy-java) implement the extraction 
> via custom code (see 
> https://github.com/xerial/snappy-java/blob/v1.1.10.5/src/main/java/org/xerial/snappy/SnappyLoader.java#L53-L56).
>
> As the community starts to move away from JNI and JNA to the new 
> Foreign Function API defined in JEP 454, are there any plans to 
> support the automatic loading of native libraries from the classpath 
> in the Java platform itself?
>
>
> Thanks,
> Jeff Yemin
>