jogl.jar architecture specific?

Hi folks,

I’m trying to make my jogl application as self-contained as possible, containing libjogl.so for both x86 and x86_64, and the classes from jogl.jar.

Initially I tried to use a single jogl.jar for both platforms (copying the .class files into my jar), but on the “foreign” platform, jogl very quickly fails. It seems that the jar file might not be architecture independent? Could this be due to struct parsing?

In any event, my main question is: do I need to include jar files for each platform? (If so, is there a good way to extract the platform-specific jogl.jar from my app’s jar and dynamically add it to the classpath?)

-Ed

jogl.jar is not platform specific. it’s the core java API and is cross platform.

it’s the native jars that contain the *.dll, *.so, etc, that are platform specific.

The jogl.jar that is shipped in the release builds is platform-independent; however, this is true because it contains all of the classes from the various platforms’ builds of jogl.jar. On the Mac, for example, MacOSXGLContext is compiled, but this class is not built during the Windows or X11 builds.

64-bit poses more of a problem. The code which GlueGen produces to access C structs from Java is targeted at a particular architecture (32-bit or 64-bit). Currently it is not possible to include the class files for both a 32-bit and a 64-bit JOGL build in the same jar file. This is a bug, and is already in the Issue Tracker, but will probably not be fixed soon; JSR-231 changes are taking priority.

You can use the release jogl.jar for the platforms we currently support. For other platforms like Linux/AMD64 you can ship a separate jogl-amd64.jar and associated libjogl.so.

Thanks for the response. That explains what I’m seeing, at least!

I would say that if there’s a 32/64 bit incompatibility that the jogl.jar is NOT platform independent (even if it’s “mostly” platform independent), but that’s a semantic thing. :slight_smile:

-Ed