Bug 575

Summary:	Allow gluegen & JOGL to be used in a single jar fat-jar executable.
Product:	[JogAmp] Gluegen	Reporter:	Bill Kuker <bkuker>
Component:	core	Assignee:	Sven Gothel <sgothel>
Status:	RESOLVED WORKSFORME
Severity:	enhancement	CC:	gouessej
Priority:	P5
Version:	2
Hardware:	All
OS:	all
Type:	---	SCM Refs:
Workaround:	---

Description Bill Kuker 2012-04-05 19:57:03 CEST

JOGL and GlueGen can not load native libraries from a fat-jar packaged executable Jar.

Fat-jar is a method where all libraries and resources are unzipped and then zipped back up into one giant executable jar. It is not the beat way to do things but it is common.

When GlueGen looks for native libraries 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.

Emails about this:

http://forum.jogamp.org/Loading-libraries-from-an-executable-JAR-is-seriously-hard-td3885657.html

Comment 1 Sven Gothel 2012-04-17 10:13:14 CEST

Copied my reply fom the forum:
+++
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.
+++

Comment 2 Sven Gothel 2012-04-17 10:14:35 CEST

P5, since it's not really required. Current native JARs per platform are available.
Nevertheless, we (?) may implement this feature, anybody likes to volunteer ?

Comment 3 Bill Kuker 2012-04-17 14:43:23 CEST

I don't have the time to help, and have also started down the jar-in-jar route anyway.

I can note that while JOGL works with the Eclipse jar-in-jar resource loader it does not seem to work with one-jar, another very common jar-in-jar loader.

Comment 4 Julien Gouesse 2012-06-06 10:35:18 CEST

(In reply to comment #0)
> Fat-jar is a method where all libraries and resources are unzipped and then
> zipped back up into one giant executable jar. It is not the beat way to do
> things but it is common.

I understand your position but I have to warn readers about the risk of such a poor approach. If the .jar extension is associated to an archiver (WinRAR under Windows, Arch under GNU Linux), your fat JAR won't work, this archiver will open it and the final user won't understand what is wrong.

Comment 5 Sven Gothel 2012-06-20 10:55:46 CEST

since jar-in-jar works and we have no prio nor resources for a single flat fat-jar, I close this bug for now.