packaging native libraries

Danno Ferrin danno.ferrin at shemnon.com
Fri Apr 19 06:37:03 PDT 2013


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


More information about the openjfx-dev mailing list