Using JOGL without the loader

Hi everyone,

We're trying to use JOGL 2 in conjunction with Java3D 1.6 in our application, but we're running into a couple issues with the integration (we're switching from Java3D 1.5).

One of the major requirements is that our application must be distributed as a single JAR, we've therefore written a loader that will extract native libraries from within our JAR and then add them to the java library path.

Unfortunately, we're having a hard time integrating this with JOGL. Is there anyway to completely disable JOGL's loading of native libraries and to handle it ourselves?

Cheers,

Arthur

Hi

You can merge JOGL and GlueGen with your existing application JAR, it is now compatible with the "fat JAR" approach. Yes there is a way of disabling this feature, I don't remember the name of the property, please look at the JOGL user's guide, I'm almost sure that I mentioned it in this document.

Hi Julien,

Thanks a lot for your reply.
We've attempted to merge the JARs by extracting all of the JOGL and GlueGen Jars and putting the extracted contents in the root of our JAR.

Unfortunately this results in a ClassNotFoundException, even though GLException is in our jar, at the correct path (/javax/media/opengl/GLException.class).

Exception in thread "main" java.lang.NoClassDefFoundError: javax/media/opengl/GLException
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at javax.media.j3d.Pipeline$1.run(Pipeline.java:143)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.media.j3d.Pipeline.createPipeline(Pipeline.java:138)
        at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:926)
        at javax.media.j3d.VirtualUniverse.<clinit>(VirtualUniverse.java:280)
        at org.tim32.seg.Main.test3D(Main.java:19)
        at org.tim32.seg.Main.main(Main.java:47)

Thanks for the pointer regarding the property, I found it on the wiki it's jogamp.gluegen.UseTempJarCache.

Cheers,

Arthur

rthur wrote

Is there anyway to completely disable JOGL's loading of native libraries and to handle it ourselves?

If you want to go old-school, you can set "-Djogamp.gluegen.UseTempJarCache=false". Then you can extract the native libs from JOGL's JAR files and put them wherever you want (they just have to be somewhere that's visible in java.library.path).

rthur wrote

We've attempted to merge the JARs by extracting all of the JOGL and GlueGen Jars and putting the extracted contents in the root of our JAR.

Unfortunately this results in a ClassNotFoundException, even though GLException is in our jar, at the correct path (/javax/media/opengl/GLException.class).

Exception in thread "main" java.lang.NoClassDefFoundError: javax/media/opengl/GLException
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at javax.media.j3d.Pipeline$1.run(Pipeline.java:143)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.media.j3d.Pipeline.createPipeline(Pipeline.java:138)
        at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:926)
        at javax.media.j3d.VirtualUniverse.<clinit>(VirtualUniverse.java:280)
        at org.tim32.seg.Main.test3D(Main.java:19)
        at org.tim32.seg.Main.main(Main.java:47)

I don't know what you did wrong. I merge all JARs together with Ant and it works very well but you have to follow a rule to name the directories in which you put the native libraries otherwise GlueGen won't find them, a static initializer will fail and you'll get strange exceptions like yours. Xerxes indicated this rule on this forum somewhere, I quoted him several times on StackOverflow and I posted an example of Ant script in a bug report about fat JARs. Where have you put the native libraries?

Ah, that makes sense.

The tree of our JAR looks something like this:

-com
-gluegen
-javax
-jogamp
-jogl
-META_INF
-newt
-native
    -windows
        -amd64
            -*.dll
        -i386
-org
    -source code

Our loader will find the correct directory based of the OS (eg. native/windows/amd64 or native/linux/i386), extract all the contents of that folder to a new temporary folder, and add that temporary folder to the java library path.

I've found some information relating to the directory names here, but does this still apply assuming we extract the pre-built libraries ourselves?

Cheers,

Arthur

Hi Wade,

Thanks for the pointer. I'm assuming we can also set this programmatically using:

System.setProperty("jogamp.gluegen.UseTempJarCache", "false");

Cheers,

Arthur

On 03/10/2014 11:24 PM, rthur [via jogamp] wrote:
> Hi Wade,
>
> Thanks for the pointer. I'm assuming we can also set this programmatically using:
>
> System.setProperty("jogamp.gluegen.UseTempJarCache", "false");

Sure ..

Actually we fall back to this mechanism if the 'TempJarCache' approach fails,
hence nothing should be required ..

~Sven

I'm starting to think something else is wrong with our setup - I've given a go at including the native libraries as specified on the wiki (as in having natives/windows-amd64/*.dll) in our JAR, but the same exception is thrown (java.lang.NoClassDefFoundError: javax/media/opengl/GLException).

Removing all the JOGL related JARs from our fat jar and manually adding them to the class path when we run our JAR also results in the same exception.

UPDATE: I've just tried running the test.bat and test.sh files, and while both appear to set the class-path correctly, they fail with:

Could not find or load main class com.jogamp.newt.opengl.GLWindow

I think I've figured out the issue - it seems to be linked to which version of the JVM is used. I'm on windows x64, and have both a 32 and 64 bit jvm installed.

If I run the JAR using a 64bit JVM everything works, however if I use a 32bit JVM i get:

Exception in thread "main" java.lang.NoClassDefFoundError: javax/media/opengl/GLException
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at javax.media.j3d.Pipeline$1.run(Pipeline.java:143)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.media.j3d.Pipeline.createPipeline(Pipeline.java:138)
        at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:926)
        at javax.media.j3d.VirtualUniverse.<clinit>(VirtualUniverse.java:280)
        at org.tim32.seg.Main.test3D(Main.java:19)
        at org.tim32.seg.Main.main(Main.java:53)

This happens with both our own loader, and the jogamp one, but only happens with fat-jars.

Does it work on a 32 bits JVM under a 32 bits OS?

The good piece of news is that if your problem is reproducible with the build-in mechanism of JOGL, it's our problem. If it's only reproducible in your own loader, it's your problem.

I still don't understand why it doesn't work for you as I daily use JOGL 2 under Windows 64 bits with a 32 bits JVM.

I've reinstalled both the 64bit and the 32bit JDK and I'm now unable to reproduce the problem, not too sure what was happening...

Thanks for taking so much time to help me out :)

Cheers,

Arthur

You're welcome. There was a similar problem 2 years ago in JOAL, someone who tested my first person shooter complained about that as he tested it with a 32 bits VM under Windows 7 64 bits. I was a bit surprised to see it again, I thought this bug was fixed. When my Java source code depends on native libraries which can't be compiled in 64 bits (some "weird" languages have no 64 bits compiler), I'm forced to use a 32 bits VM :(

It was quite a weird error indeed - I'm wondering if maybe it was a JVM related bug? Reinstalling the JVM bumped my java version from 7u45 to 7u51.

Same here.. the only reason I have a 32bit JVM installed is because I need some software that only comes packaged with 32 bit .dlls...

Thanks for everything!

Arthur