packaging native libraries

[Mark Howe]

Hi Danno, can you file a issue for this. 

Plus we are considering options for how to proceed with the packager, so will consider the idea of the javafx namespace.

Thanks
Mark

On Apr 19, 2013, at 9:23 AM, Danno Ferrin <danno.ferrin at shemnon.com> wrote:

> My bad.  Looks like the code I was running at work has a fallback path for
> when the loadLibrary fails.  Looks like it worked so seamlessly I had
> assumed it was working.  That's the drawback of a good QA team I suppose.
> 
> 
> On Fri, Apr 19, 2013 at 10:01 AM, Johan Vos <johan at lodgon.com> wrote:
> 
>> 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
>>> 
>> 
>> 
> 
> 
> -- 
> 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