De la investigación que he hecho en el pasado, sólo hay dos maneras de obtener bibliotecas nativas cargadas: La modificación de java.library.path y utilizando System.loadLibrary (me siento como la mayoría de la gente hace esto), o utilizando System.load con una ruta absoluta.
Como has mencionado, jugar con java.library.path puede ser molesto en términos de configuración de SBT y Eclipse, y no creo que sea posible hacerlo automáticamente para un archivo ejecutable.
De modo que deja System.load. En términos de escribir sus propias bibliotecas nativas, lo que puede hacer es:
- Crear una tarea SBT que recopila sus fuentes nativas (con
javah y gcc), dando como resultado la toma .so archivos y los archivos .so que depende on, los pone en un jar (como recursos) en el directorio de destino y agrega la ruta al jar al unmanagedJars in Compile.
- Cree un método Scala para cargar una biblioteca. En lugar de llamar al
System.loadLibrary, usará Class.getResourceAsStream para leer la biblioteca, File.createTempFile para escribirla en algún lugar del sistema de archivos, y System.load para cargarla en la JVM.
- Ahora, en lugar de llamar al
System.loadLibrary como lo haría antes, llame al MyClasspathJniLoader.loadLibrary.
Eso funcionará con SBT run, Eclipse y archivos ejecutables sin configuración adicional (aunque no sé cómo Proguard sabe qué recursos incluir).
Ahora, en cuanto a las bibliotecas nativas de terceros que ya se han escrito, algunas de ellas como jblas ya usan este enfoque de "jar gordo". Si esperan que configures java.library.path y luego llamen al System.loadLibrary cuando lo deseen, tendrás que hacer algo de magia para que funcione.
No he probado esto, pero esta solución podría funcionar:
- uso una tarea similar SBT para poner todas las bibliotecas en su ruta nativa en un frasco como recursos, y poner el frasco en el clsaspath.
- Cree un método Scala que tome una función y una lista de nombres de biblioteca, cree un directorio temporal, lea esas bibliotecas de los recursos del jar en archivos en el directorio temporal, agregue el directorio temporal al
java.library.path, llame a la función de pasado, y finalmente revierte el java.library.path a lo que era antes.
- La primera vez que llame a la biblioteca nativa (cuando presumiblemente se inicializará estáticamente y realizará la llamada
System.loadLibrary), ajuste esa llamada en particular en su método con la lista de bibliotecas que cargará. De esta forma, cuando llame al System.loadLibrary, todas sus bibliotecas estarán en java.library.path y se cargarán correctamente.
Obviamente, esto es molesto ya que se debe inicializar manualmente la biblioteca de terceros antes de usarlo, pero parece más factible para envolver todos los puntos de inicialización (sus principales funciones y las inicializaciones de prueba) que lo hace para obtener toda de sus herramientas para establecer java.library.path correctamente. Y puede ser aún más fácil que eso si ya tiene su propia capa de abstracción sobre la biblioteca de terceros, por lo que solo hay un punto de inicialización que debe ajustar.
Si eso parece una solución realista, puedo agregar más detalles sobre la tarea SBT o los métodos de envoltura de Scala si está confundido.