Note: I renamed the solaris .so files so they would all have unique filenames; not sure if this will be an issue or not.

When I run this code, I get a message box from java.exe that tells me "A required DLL, jawt.dll, is not found.." etc. I checked my JRE and JDK directories; sure enough, it's there. I also ran another AWT/Swing app to verify that it's working. So, something in my code has to be causing this issue.

Does anyone have any suggestions on how to fix the problem, or another method for solving the dynamic loading quandary?

The manual loading of the JAWT via System.loadLibrary("jawt") doesn't fail. It works around the fact that loading JOGL (which depends on JAWT) doesn't work on most platforms unless the JAWT has been dynamically loaded first.

What version of Cg are you using? It looks like those functions were present in the 1.3 release of Cg and are absent in the current 1.4 release.

We would probably have to release another version of JOGL to bring it up to date with Cg 1.4. I'm a little reluctant to do that right now because it is becoming a maintenance problem preventing us from doing work on the JSR-231 APIs. Can you find a copy of the Cg 1.3 runtime?

As it stands, I have Cg 1.4 installed, but I'm not using Cg at all in this or any other project. I just installed it to play around with it one day. If I need Cg in order to make jOGL work, I'll get whatever version is needed, but if I don't plan on using Cg, could I just disable it or uninstall the runtime?

Taking out the Cg stuff, I now can't get the .jar file to dynamically load before it tries to create a subclass of its contents, so it's throwing a NoClassDefFound. As it stands, the following code is in a static {} block in the class where main() is executed.

So, trying to see what would happen, I commented this part out and then loaded the .jar using the -classpath command line option. When I did, I'm now getting an UnsatisfiedLink because awt.dll is already loaded. This is where I'm loading the .dll files:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

// Manually load AWT to work around the problem with it not finding it System.loadLibrary("awt");System.loadLibrary("jawt");

You only told me to loadLibrary on jawt.dll, but when I did, I started getting error boxes that it couldn't find awt.dll either, and adding that line stopped those boxes. Presumably, I now have to find a way to tell the JVM not to load AWT again.

Please post stack traces for some of the exceptions you're seeing. I suspect the NoClassDefFoundError is occurring because of the delegation path of your class loaders. If you make a subordinate class loader to load JOGL and are trying to load classes which reference JOGL then those classes must be loaded from the same loader or a subordinate loader of the other one, because otherwise the "current" class loader (the one which your subordinate loader will delegate to by default) won't know how to find the JOGL classes. Class loader delegation occurs up to the parent loader, not down to the child loader.

You need to call Toolkit.getDefaultToolkit() before trying to manually System.loadLibrary("jawt"). Do not call loadLibrary("awt"). It is loaded by the boot loader and loading it manually will break the JDK's internal loading of it as you've found.

// this is called from a static initializer block in the class where main() is publicstaticvoidloadOpenGL() { // Manually load AWT to work around the problem with error boxes coming up claiming it's not found. // Apparently AWT has to be loaded -before- jogl's .dll files or all Hell breaks loose.java.awt.Toolkit.getDefaultToolkit();System.loadLibrary("jawt");

All I want to do is get the dlls and jars loading in such a way as to prevent a lot of command line switches. It seems that I shouldn't be the first person to have wanted to do this - what am I missing here?

Calling net.java.games.jogl.impl.NativeLibLoader.disableLoading() before doing any JOGL-related operations will avoid the exception above.

In the past two years there has only been one other request to do something similar to what you're doing (which is why the enableLoading/disableLoading methods are exposed). I think most people are deploying JOGL apps with Java Web Start which takes care of this automatically. During development it isn't difficult to write some simple wrapper scripts which set up either the PATH/LD_LIBRARY_PATH/CLASSPATH environment variables or -Djava.library.path/-classpath.

// Manually load AWT to work around the problem with error boxes coming up claiming it's not found. // Apparently AWT has to be loaded -before- jogl's .dll files or all Hell breaks loose.java.awt.Toolkit.getDefaultToolkit();System.loadLibrary("jawt");

Hello,Thank you very much for the useful info you provide.I tried the dynamic loading of the native libraries, and it works fine under windows and linux.

I had a problem on mac, but finally I managed to figure it out.So it works now on mac as well!The difference from Jaeden's code is, that I do not load jawt on mac.I had a lot of trouble from mismatching versions of jar and native files.Hope this helps.

I want to do this cause on Windows i'm able to put the jar into the lib/ext folder and the DLLs into the bin folder of the JRE the first time, but i need a cross platform solution. On Linux i can't do this, cause the JRE folders are 99% with root acces, so i cannont use this method with normal user. This solution seems good cause i put the files into the home directory of the user (i'll adapt the code for others os after i'll be able to load the stufss dynamically).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org