packaging native libraries

[Mark Howe]

Thanks for entering that issue.

Mark


On Apr 24, 2013, at 5:27 PM, danno.ferrin at shemnon.com wrote:

> 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.
> 
> 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
>