Login  Register

Re: JOGL upgrade fails

Posted by Wade Walker on Feb 12, 2012; 9:26pm
URL: https://forum.jogamp.org/JOGL-upgrade-fails-tp3728805p3738440.html

clevengr wrote
What I'm confused about is how the underlying system is finding those .dlls when they're not in the PATH.  Is there something magic (defined as: anything the user doesn't understand) about how Java processes .jar files (like gluegen-rt.jar) that causes it to look for .dlls in a jar in the the same location so that they don't need to be specified in the PATH?
The magic is, Sven added a new feature to JOGL  Previously, JOGL would simply do a System.loadLibrary() to load the native DLLs (this looks for DLLs in java.library.path, which the JVM sets up in a system-dependent way when you start it). Now what happens is, JOGL first looks at the path to the JAR file it's running from, then checks that directory to see if it contains "natives" JARs. If so, JOGL unpacks the DLLs from inside the "natives" JARs to a cache directory, then loads the DLLs from there instead of from the normal library path. If there are no "natives" JARs, JOGL just loads the DLLs the old way.

This is the same way SWT has worked for a long time. It lets the users avoid having to know about the DLL/SO/JNILIB files, so a library like JOGL that needs native code can appear to be a simple JAR like any other library.

One possible disadvantage of this system is that when you upgrade your JOGL JARs, the DLL caching system has to be smart enough to overwrite the old DLLs (but it can't just always overwrite them, since this would slow down startup times). There can also be problems finding a directory where the user has write permissions, depending on the OS and how the user permissions are set up. But once these problems are solved, it's a good system.