• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1039
  • Last Modified:

Problems with Java Applet and JOGL

All,
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


AccessController.doPrivileged(new PrivilegedAction() 
{
   public Object run() 
   {
      try
      {		       			
          String lib = System.getProperty("java.io.tmpdir");
          copyFile("http://www.mydomain.com/" + System.mapLibraryName("jogl"), lib + System.mapLibraryName("jogl"));
          copyFile("http://www.mydomain.com/" + System.mapLibraryName("jogl_awt"), lib + System.mapLibraryName("jogl_awt"));
          copyFile("http://www.mydomain.com/" + System.mapLibraryName("jogl_cg"), lib + System.mapLibraryName("jogl_cg"));
          copyFile("http://www.mydomain.com/" + System.mapLibraryName("gluegen-rt"), lib + System.mapLibraryName("gluegen-rt"));
		       			
           System.load(lib + System.mapLibraryName("jogl"));
           System.load(lib + System.mapLibraryName("jogl_awt"));
           System.load(lib + System.mapLibraryName("gluegen-rt"));
	
	// code that uses libraries        	   
           wwd = new WorldWindowGLJPanel();

Open in new window

0
mwarble
Asked:
mwarble
1 Solution
 
samikoivuCommented:
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.
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now