packaging native libraries

[Johan Vos]

It doesn't work for me, on Windows, Linux or MacOs. Do you load the DLL
using System.loadLibrary() rather than System.load()? I printed the value
of java.library.path, and it was empty (as I would expect). In that case,
System.loadLibrary() should always fail, I think.

I checked how e.g. the Glass library is loaded in JavaFX, and
com.sun.glass.utils.NativeLibLoader does exactly what I would expect:
 // Look for the library in the same directory as the jar file
        // containing this class.
        // If that fails, then try System.loadLibrary as a last resort.
Loading the class from the jarfile is done using System.load(libFileName);

There is a clever but dirty trick to circumvent the java.library.path
issue, as pointed to me by Jose Pereda Llamas:
http://blog.cedarsoft.com/2010/11/setting-java-library-path-programmatically/
That should work, but there is no guarantee this will work forever, as it
relies on internal logic for "resetting" the java.library.path.

- Johan


2013/4/19 Danno Ferrin <danno.ferrin at shemnon.com>

> It worked for me last week.  I passed in the DLLs along with the jars as a
> list of files, and the DLLs wound up in the /app dir for windows alongside
> all the other jars, and the DLLs loaded just fine.
>
> YYMV, I was doing this with my Gradle plugin, not the command line, or
> ant, or  maven (I got 5 months to formalize this for my javaone talk).
>  Also, I only did it with DLLs, not dynlibs or SOs.  I have no mac or linux
> binaries to test it against anyway.
>
> So basically, treat the library as a jar when packaging.
>
>
> Also, I don't know about the javax.whatever namespace.  If we need a
> rename I would be more in favor of something more like
> net.java.openjdk.javafx .packager.  The javax namespace implies to me we
> would want to use it in a typical runtime, not as a build time tool.  It
> also implies more stability than native packaging processes will ever be
> able to offer, what with each native platform coming up with new packaging
> options at random intervals.  (First it's exe, then it's jar, or app, then
> dmg, now it's mac store, oh wait, .debs are out of fashion, now they need
> to be .mobapp... etc etc.)
>
>
> On Fri, Apr 19, 2013 at 1:16 AM, Johan Vos <johan at lodgon.com> wrote:
>
>> Hi,
>>
>> The javafxpackager is a great tool. I think it would actually make sense
>> to
>> move some of the code (from src/com/sun/javafx/tools/packager) to the
>> javax. namespace and make it a public API, rather than having a single
>> script.
>>
>> But I have an issue: I need to bundle an external Java library, that also
>> comes with a native library. Bundling itself is not a problem with the
>> javafxpackager, and loading the native library is also achievable, by
>> unpacking the native lib, storing it in a temp file and loading it with
>> System.load(String). However, if the library is also loaded using
>> System.loadLibrary(String), the java.library.path is searched for the
>> library.
>>
>> One solution is that external Java libraries should not attempt to load
>> the
>> native libraries themselves, rather rely on the developers to load the
>> libraries. But since in most cases you don't control these external
>> libraries, that will not work in all cases.
>>
>> However, with a growing tendency towards bundled native applications, I
>> think the management of native dependencies is becoming more important.
>>
>> Ideas?
>>
>> - Johan
>>
>
>
>
> --
> There is nothing that will hold me back.  I know who I am....
> I remember wher I came from, and I feel stronger for knowing.
> Zane, Ninja of Ice.  Ninjago S01E07
>