Posted by Sven Gothel on Dec 05, 2012; 3:52pm
URL: https://forum.jogamp.org/ZipException-when-loading-native-jars-tp4027387p4027412.html

On 12/05/2012 07:06 AM, ryanmohr [via jogamp] wrote:
> It would help if you could describe the jar-in-jar loader
> better.
>
> For example, in Test-1 of
> https://jogamp.org/bugzilla/show_bug.cgi?id=522#c7 I'm surprised that the jogl
> jars are found under lala01_lib.  What is the full list of paths that are
> checked in this case?

Test-1 is not Jar-In-Jar, but simple Side-by-Side,
hence it's simply the default case.

    ./lala01.jar
    ./lala01_lib/jogl.all.jar
    ./lala01_lib/jogl-all-natives-linux-amd64.jar
    ./lala01_lib/... etc ..

Test-2 is Jar-In-Jar:

   ./lala02.jar:
      Manifest-Version: 1.0
      Rsrc-Class-Path: ./ gluegen-rt-natives-linux-amd64.jar gluegen-rt.jar
                          jogl-all-natives-linux-amd64.jar jogl.all.jar
      Class-Path: .
      Rsrc-Main-Class: Test01
      Main-Class: org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader

meaning that the Jar contains the Jars listed in the manifest
in it's root folder.

Jar-In-Jar simply works by passing the big jar to the commandline.
The used classloader then is able to simply use resources from within
the jar, exposed as a normal URI.
Hence our GlueGen native lib loading mechanism simply uses the
inner-jar URI and appends the native jar files to it.
No actual extraction happens until then.
After having the native JAR URI (pointing to the native jar file
inside the jar), we extract it and proceed as usual.

>
> From my understanding, the auto extraction process simply copies the required
> libraries out of the necessary jars into a temporary directory and loads them
> from there.  If that's the case, why does it matter where the native jars are
> as long as they're included in the jar's class path?

They shall not be in the jar's class path, but simply parallel
to the non-native jar file with the same basename!
I would rename jogl/ -> jogamp/

>       jogl-all.jar
        jogl-all-natives-linux-amd64.jar
        ...
>       gluegen-rt.jar
        gluegen-rt-natives-linux-amd64.jar
        ...
>       ... and so on for all the required jars
>
> Onejar apparently doesn't support subdirectories in the lib dir so we flatten
> the lib structure before packaging it.

as long the extracted stuff by Onejar will result in something like:
 /wherever/
   jogl-all.jar
   jogl-all-natives-linux-amd64.jar
   ...
   gluegen-rt.jar
   gluegen-rt-natives-linux-amd64.jar
   ...

it should work.

The basename, e.g. gluegen-rt does not matter,
but the -native-<OS.and.ARCH> part.

Can you provide a test case?
  - a project which builds a onejar binary? (-> all open source)
  - a onejar binary ? (-> if onejar is not open source)

Is Onejar freely available ? Is it open source ?

+++

The original exception shows me that the jar file could not be found,
or loaded. Maybe you can also provide the complete exception w/ stack trace,
maybe even a log file w/ all jogamp debug flags enabled (-> Wiki/FAQ/Bug..).

In such case the traditional way (native lib path) is being used.

~Sven