How to skip native library extraction?

[tobiascapin]

Is it possibile to disable the automatic native library extraction?
I'm providing the native library in the java.library.path, so I would like to avoid the temp file extraction. However I see an empty temp nativelib-loader_xxxxxxxxxxxxx folder is created every time when I open a serial port.

Thanks for your support.

[hiddenalpha]

I don't know the loader part. I don't know if it can be disabled.

It feels as such a feature could help us too. AFAIK our project is using a custom (as in handmade) build which completely strips the loader library plus some of the unused libs away. Due to this, our project is stuck with an old release and this feature may enable us to jump back to the officially released artifacts again.

[tobiascapin]

I could remove it forking the project and removing this lines from SerialNativeInterface.java:

 NativeLoader.setJniExtractor(new DefaultJniExtractorStub(null, System.getProperty("jssc.boot.library.path")));
 NativeLoader.loadLibrary("jssc");

and replacing them with

System.loadLibrary("jssc");

I wanted to avoid org.scijava.nativelib dependency, this is the reason why I replaced NativeLoader.loadLibrary line too.

I don't like to have a custom version, I hope somehow will be possibile to disable the nativeload by some future option.

[pietrygamat]

This has been tackled in #92. Are you using jssc 2.9.3+?

[tresf]

Whoops, nevermind,.@pietrygamat answered it already.

[tresf]

Documentation: https://github.com/java-native/jssc/wiki/Examples#override-native-library-path

[pietrygamat]

After closer inspection, the reported issue: empty directory being created is actually true regardless of using jssc.boot.library.path property. JSSC will load native lib from library/classpath or specified boot path if present, so it will skip the extraction step, however empty temp dir (removed at jvm exit) is there anyway.

There is no obvious way to work around that, as it happens in NativeLoader class static initialization block - something that should maybe be reported upstream?

I wanted to avoid org.scijava.nativelib dependency

You mean as in remove nativelib jar from the classpath? Not untill references are removed from java files. Which means the logic for finding correct lib to load must be either rewritten within JSSC (back to its roots) or excluded from this project and then either ceded onto end users (breaking any compatibility) or extracted to a separate artifact to be used by users relying on that. Given how much controversy any aproach to locating libs packaged inside the jar causes, no option seems better than the next ;)

[tresf]

I wanted to avoid org.scijava.nativelib dependency

Which means the logic for finding correct lib to load must be either rewritten within JSSC (back to its roots)

Me too. I would be happy to discuss it's removal. The original project didn't have this requirement and the nativelibloader was added in #14 as an effort to simplify and standardize the codebase. In hindsight, I think the project would have been better off updating its old extraction code. If someone wants to spearhead this effort, I would be receptive to it.

JSSC will load native lib from library/classpath or specified boot path if present, so it will skip the extraction step, however empty temp dir (removed at jvm exit) is there anyway

Good observation. This is likely a bug.

as it happens in NativeLoader class static initialization block - something that should maybe be reported upstream?

Agreed.

I could remove it forking the project and removing this lines from SerialNativeInterface.java:

 NativeLoader.setJniExtractor(new DefaultJniExtractorStub(null, System.getProperty("jssc.boot.library.path")));
 NativeLoader.loadLibrary("jssc");

and replacing them with

System.loadLibrary("jssc");

This fix is sort of backwards from the project direction as it assumes that the native libraries are magically discoverable however we'd consider a stop-gap that calls System.load("/path/to/jssc.so"), but this will not immediately avoid the nativelibloader requirement, so I think a proper removal of this dependency is the best use of developer resources.

Since the originating issue title is fundamentally resolved, I will ask @tobiascapin to provide a follow-up so we can decide if the bug report should remain open under a different title, opened as a new issue, or require future discussion (either here or on Discord). A response is required or this bug will be closed.