- For individual users
- Instant access to solutions
- Ask your tech questions
- Start your 30-day Free Trial
Main Topics
Browse All TopicsAll,
I am trying to get JOGL to work with an applet and I am exasperated. I'll say up front for reasons I won't explain I do not want to use the JNLP Launcher. I just want to use a plain old signed applet with the normal HTML tags. I have spent many hours on this problem and have taken several routes and still haven't succeeded. Here's where I am in the process and the approach I'm taking.
1. Launch a signed applet via HTML with your standard applet tag.
2. To the best of my knowledge, because System.load and System.loadLibrary will only load a library from a local drive not over a network using a URL, I download the required library files (jogl.dll, jogl_awt.dll, jogl_cg.dll, and gluegen-rt.dll) by copying the files from the webserver to a local drive on the end user's machine. Currently I am using the java.io.tmp property as the local directory. This seems to work fine.
3. I then use System.load to load the libraries from java.io.tmp. This seems to work fine. No exceptions.
4. Steps 3 and 4 are done in AccessController doPriviedged block to satisfy the security requirements.
Here's the problem.
5. When the code that actually uses the librairies is executed, it tries to reload the libraries from java.library.path. Of course the library files aren't there, because they are in java.io.tmp, and an exception is thrown.
So here's my questions/comments:
1. Does anybody know why the system would try to reload the libraries when they have already been loaded?
2. It seems pretty conclusive that java.library.path cannot be changed at runtime, so that isn't an option. Correct me if I'm wrong.
3. I've tried to copy the files to java.library.path, but that is a list of directories, most which require special permision to write to. That doesn't seem to be an option. Correct me if I'm wrong.
I am out of ideas on this, so any input would be greatly appreciated.
I'll attach a short code snippet that shows how I'm loading the libraries.
Thanks,
M. Warble
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Business Accounts
Answer for Membership
by: samikoivuPosted on 2008-11-27 at 19:46:26ID: 23053615
Hi,
1. Does anybody know why the system would try to reload the libraries when they have already been loaded?
I tested this on a standalone Java and I was able to reproduce the problem. As far as I can see, the problem is that JOGL code explicitly calls (code which calls) the System.loadLibrary method, which wants the library to be on the java.library.path. So while you're successfully loading the libraries with the System.load, by specifying the full path, the JOGL code tries to call the System.loadLibrary variant, which isn't intelligent enough to see if the library in question was already loaded and it throws an exception.
Unfortunately as the JOGL code probably runs in a static initialization block there is no way to catch the exception and the exception prevents the class from being loaded and I know of no work-around for that.
2. It seems pretty conclusive that java.library.path cannot be changed at runtime, so that isn't an option.
I believe you are correct.
3. I've tried to copy the files to java.library.path, but that is a list of directories, most which require special permision to write to. That doesn't seem to be an option.
I belive you're referring to operating system permissions. If you're targeting all the major operating systems that does seem complicated. It does seem terribly invasive depending on who will be using your applet. Might not be impossible, though.