Re: Loading libraries from an executable JAR is seriously hard.
Posted by Sven Gothel on Apr 05, 2012; 12:14am
URL: https://forum.jogamp.org/Loading-libraries-from-an-executable-JAR-is-seriously-hard-tp3885657p3885944.html
On 04/04/2012 11:46 PM, bkuker [via jogamp] wrote:
>
>
> I am trying to use JOGL (2.0 rc5) in a standalone Java app run from an
> executable JAR.
>
> The app's jar is packaged by re-zipping all of the libraries into one fat
> jar. It's not my app, I can't change that.
>
> The JogAmp projects do seem to know how to pull a native library out of a
> JAR (I assume they write it to a temp directory), but the way they find that
> resource seems really complex... It looks for the JAR that GlueGen came in,
> then looks for a jar in the same directory, using a naming convention
> including the architecture, and then gets native libraries from that jar.
>
> This makes it really tough to package it into a single far jar. The eclipse
> jars-in-a-jar method works, but the "fat jar" method does not.
>Very good assessment & description, thank you.
> Is there any way I can just put the natives in my Jar, and give them to
> GlueGen & JOGL as streams (getResourceFromStream) or some such?
Not as it is today, but we may add something to serve such a need.
Currently the only way to determine the right JAR file for each platform
is the JAR file name - as you pointed out correctly.
The native plain library files itself don't have a unique name.
The current schema, one native JAR file per platform very well
serves the traditional Applet/Webstart deployment since it saves
bandwidth and it also serves most stand alone application.
Having a fat JAR would at least require the native libraries to reside
in a subfolder using our naming convention.
Such implementation would be doable with minor changes to the current code.
However, I don't see a conflict w/ Jar in Jar, which I personally would favor
here. It also gives one the opportunity to use
the original [signed] JAR files, so you can maintain the files
origin and identity.
Well, using a fat JAR here implies that in the JOGL layer,
the fat JAR content is already 'known' and available to the classloader.
Hence we can skip extracting files, but 'just' need to find the platform's
subfolder and continue there (copy files to temp folder and allow them to
loaded by the classloader).
We may even be able to skip the copy part, if it is ensured that only one
ClassLoader will access those libraries (no Applets .. ).
Anybody out there who cannot live with the current use case,
restricted to native Jar files per platform incl. Jar-In-Jar ?
For sure this won't be done for RC6.
Please add a bugreport (enhancement) with the content of your and my writings
and we can vote/discuss it further.
Thank you.
Cheers, Sven
URL: https://forum.jogamp.org/Loading-libraries-from-an-executable-JAR-is-seriously-hard-tp3885657p3885944.html
On 04/04/2012 11:46 PM, bkuker [via jogamp] wrote:
>
>
> I am trying to use JOGL (2.0 rc5) in a standalone Java app run from an
> executable JAR.
>
> The app's jar is packaged by re-zipping all of the libraries into one fat
> jar. It's not my app, I can't change that.
>
> The JogAmp projects do seem to know how to pull a native library out of a
> JAR (I assume they write it to a temp directory), but the way they find that
> resource seems really complex... It looks for the JAR that GlueGen came in,
> then looks for a jar in the same directory, using a naming convention
> including the architecture, and then gets native libraries from that jar.
>
> This makes it really tough to package it into a single far jar. The eclipse
> jars-in-a-jar method works, but the "fat jar" method does not.
>
> Is there any way I can just put the natives in my Jar, and give them to
> GlueGen & JOGL as streams (getResourceFromStream) or some such?
Not as it is today, but we may add something to serve such a need.
Currently the only way to determine the right JAR file for each platform
is the JAR file name - as you pointed out correctly.
The native plain library files itself don't have a unique name.
The current schema, one native JAR file per platform very well
serves the traditional Applet/Webstart deployment since it saves
bandwidth and it also serves most stand alone application.
Having a fat JAR would at least require the native libraries to reside
in a subfolder using our naming convention.
Such implementation would be doable with minor changes to the current code.
However, I don't see a conflict w/ Jar in Jar, which I personally would favor
here. It also gives one the opportunity to use
the original [signed] JAR files, so you can maintain the files
origin and identity.
Well, using a fat JAR here implies that in the JOGL layer,
the fat JAR content is already 'known' and available to the classloader.
Hence we can skip extracting files, but 'just' need to find the platform's
subfolder and continue there (copy files to temp folder and allow them to
loaded by the classloader).
We may even be able to skip the copy part, if it is ensured that only one
ClassLoader will access those libraries (no Applets .. ).
Anybody out there who cannot live with the current use case,
restricted to native Jar files per platform incl. Jar-In-Jar ?
For sure this won't be done for RC6.
Please add a bugreport (enhancement) with the content of your and my writings
and we can vote/discuss it further.
Thank you.
Cheers, Sven
signature.asc (910 bytes) | Free forum by Nabble | Edit this page |