I'd like to learn how they do it. Because last time I've looked at this, the suggested solution was to copy the binaries from claspath (eg: the jar) into a temporary folder then load it from there. It feels icky :)
Decompiled class file:
try {
var4 = File.createTempFile("libzstd-jni-1.5.0-4", "." + libExtension(), var0);
var4.deleteOnExit();Though in the example given, I do see your point now. You'd have to make sure the DLL was unloaded before the delete-on-exit happened.
Runtime.getRuntime().addShutdownHook(...)1: https://docs.oracle.com/en/java/javase/22/docs/specs/jni/inv...
https://github.com/java-native-access/jna/blob/40f0a1249b5ad...
Do NOT force the class loader to unload the native library, since
that introduces issues with cleaning up any extant JNA bits
(e.g. Memory) which may still need use of the library before shutdown.
Following the blame back to 2011, they did unload DLLs before https://github.com/java-native-access/jna/commit/71de662675b... Remove any automatically unpacked native library. Forcing the class
loader to unload it first is only required on Windows, since the
temporary native library is still "in use" and can't be deleted until
the native library is removed from its class loader. Any deferred
execution we might install at this point would prevent the Native
class and its class loader from being GC'd, so we instead force
the native library unload just a little bit prematurely.
Users reported occasional access violation errors during shutdown.You can just load as a resource. We do this internally since much of network stack is C. But we use JNI because code is older than Java 22.
Stackoverflow is full of "copy it into a temp file" solutions. ChatGPT keeps saying "sorry" but still insists on copying it into a temp file :)
[0] - https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi...
new FileOutputStream(tmpFile)
Apologies.