FFM: Ability to load libsecp256k1 from a JAR

[msgilligan]

The current implementation relies on being able to find the secp256k1 native library via the SECP_EXAMPLES_JAVA_OPTS="-Djava.library.path=$HOME/.nix-profile/lib mechanism.

From Issue #79

When distributing a client application, one cannot rely on the presence of any external libraries (like secp256k1). Generally, the approach is to package these libraries in the application jar. When the library is used, it is first extracted to a temporary location on the user's drive and loaded directly from there using System.load(filepath). However, the approach used by jextract is different - it expects to be able to find the library on java.library.path which must be specified on application startup, since it is only read once. The problem is in the static initializer:

secp256k1-jdk/secp-ffm/src/main/java/org/bitcoinj/secp/ffm/jextract/secp256k1_h.java

Lines 71 to 73 in 453da0b

	static {
	System.loadLibrary("secp256k1");
	}

I was able to get it working by commenting this block out and performing the library loading [manually]

[craigraw]

Having said the above, I would actually like to try loading from the file system by placing the library within the application image alongside the other JVM libs. This means it would be writeable only by root for normal Linux sudo dpkg -i ... type installs.

[msgilligan]

placing the library within the application image alongside the other JVM libs.

I assume we should be doing this as part of the jlink step?

[msgilligan]

I did a quick test on macOS and got it working with jlink (with one manual cp command not included in the build/PR). See:

• PR WIP: support a jlink'ed schnorr-example #240

[craigraw]

Agreed, my research indicates this the correct approach.

I still think there is value in including the libraries in the JAR as a fallback. I am investigating whether it is reasonable to extract native libraries from dependencies during the build process so loading might be attempted with System.loadLibrary first before falling back to the extraction and System.load approach.