Re: packaging native libraries
danno.ferrin at shemnon.com
danno.ferrin at shemnon.com
Wed Apr 24 17:27:00 PDT 2013
RT-29984 for the native libs. I’ll leave the repackaging to be a non-bugged issue.
Sent from Windows Mail
From: Mark Howe
Sent: Wednesday, April 24, 2013 5:57 PM
To: Danno Ferrin
Cc: Johan Vos; openjfx-dev at openjdk.java.net Mailing
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.
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:
>> 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:
>>>> The javafxpackager is a great tool. I think it would actually make sense
>>>> 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
>>>> 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
>>>> One solution is that external Java libraries should not attempt to load
>>>> 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.
>>>> - 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
More information about the openjfx-dev