-Djava.library.path=<path to native libraries>
From the research I've done in the past, there are only two ways to get native libraries loaded: modifying
java.library.path and using
System.loadLibrary (I feel like most people do this), or using
System.load with an absolute path.
As you've alluded to, messing with
java.library.path can be annoying in terms of configuring SBT and Eclipse, and I do not think it's possible to do automatically for an executable jar.
So that leaves
System.load. In terms of writing your own native libraries, what you can do is:
gcc), takes the resulting .so files and any .so files it depends on, puts them in a jar (as resources) in the target directory, and adds the path to the jar to
unmanagedJars in Compile.
System.loadLibrary, it will use
Class.getResourceAsStreamto read the library,
File.createTempFileto write it somewhere on the filesystem, and
System.loadto load it into the JVM.
System.loadLibraryas you would before, call
That will work with SBT run, Eclipse, and executable jars without any extra configuration (although I don't know how proguard knows which resources to include).
Now as to third party native libraries that have already been written, some of them like jblas already use this "fat jar" approach. If they expect you to set up
java.library.path and then they call
System.loadLibrary when they feel like it, you'll need to do some magic to make that work.
I haven't tried this, but this solution might work:
java.library.path, calls the passed in function, and finally reverts the
java.library.pathback to what it was before.
System.loadLibrarycall), wrap that particular call in your method with the list of libraries it will load. That way, when it calls
System.loadLibrary, all of its libraries will be on
java.library.pathand will be loaded successfully.
Obviously this is annoying since you have to manually initialize the third party library before using it, but it seems more feasible to wrap all of the initialization points (your main functions and test initializations) than it does to get all of your tools to set
java.library.path correctly. And it may be even easier than that if you already have your own layer of abstraction above the third party library, so there's really only one initialization point you have to wrap.
If that seems like a realistic solution, I can add more details about the SBT task or Scala wrapper methods if you're confused.