I am increasingly disappointed to see that Java WebStart has become the de-facto deployment solution for Jogl-based applications. For Java applications and games, WebStart may be a reasonable choice, but I for one would still like to see the power of OpenGL available to Java applets. I am an educator, and a firm believer that Java applets embedded in a host web page that supplies the desired instructional context are an effective pedagogical tool. By forcing the application to open in a separate window, WebStart destroys the tight integration between computer exercise and the surrounding context that is vital to the educational value of the piece. This is exacerbated by the distraction of having to negotiate multiple dialogs before the exercise can actually begin. When you consider that having three or four applets per web page is not unusual, you are left with a deployment solution that is at best impractical for this intended use. If there are workarounds for these problems using WebStart, I'd be glad to hear them; otherwise, let's admit that Jogl applets are desireable for some developers and stop pretending that WebStart is the answer to all deployment scenarios. For the future of Jogl (and, yes, my own selfish interests), I would urge the expert participants of this Forum to undertake a serious effort to provide alternatives.

It's pretty tricky to do what's required inside the context of a browser but not impossible. The steps involved are thusly:

1. You must have a fully signed applet.2. The applet, on first run, needs to create a directory in some well-known but interference-proof location. I would recommend ${user.home}/appletname/native.3. The DLLs are copied into there from their source jars4. The Java-side code needs to be able to call System.loadLibrary(System.getProperty("user.home")+"/"+appletname+"/"+native+"/jogl.dll") or something. Therefore JOGL (and LWJGL) would need a few subtle adjustments to allow them to load from custom paths.

It's not actually all that ugly a solution. I plan to try something along these lines myself to get Ultratron working in a browser.

1. You must have a fully signed applet.2. The applet, on first run, needs to create a directory in some well-known but interference-proof location. I would recommend ${user.home}/appletname/native.3. The DLLs are copied into there from their source jars4. The Java-side code needs to be able to call System.loadLibrary(System.getProperty("user.home")+"/"+appletname+"/"+native+"/jogl.dll") or something. Therefore JOGL (and LWJGL) would need a few subtle adjustments to allow them to load from custom paths.

it s not completely true what you re saying, cas. the applet itself doesn t need to be signed. check out this applet we threw together.

the thing is, you need the files installed as extensions in your VM to run this unsigned applet.to achieve that we wrote an installer, which btw needs to be a signed applet, that installs all necessary files in your VM.we plan to release the installer as a more general solution, for all kinds of extensions.

the basic idea is to ask the java enabled browser about the location of the VM it uses and then copy the stuff there. on OS X this works pretty nice because the extension policy is very clear. on windows it usually works. the good thing is you one only has to install the extension once.

Installation of shared files for applets can only lead to trouble. I'd be pretty miffed if something got installed in lib/ext that I didn't explicitly put there myself - it's a source of many evil things. Besides, you still need to sign the installer, so why not just instead sign your applet and do it like I said, and all will be well, in all circumstances...?

It's pretty tricky to do what's required inside the context of a browser but not impossible. The steps involved are thusly:

1. You must have a fully signed applet.2. The applet, on first run, needs to create a directory in some well-known but interference-proof location. I would recommend ${user.home}/appletname/native.3. The DLLs are copied into there from their source jars4. The Java-side code needs to be able to call System.loadLibrary(System.getProperty("user.home")+"/"+appletname+"/"+native+"/jogl.dll") or something. Therefore JOGL (and LWJGL) would need a few subtle adjustments to allow them to load from custom paths.

It's not actually all that ugly a solution. I plan to try something along these lines myself to get Ultratron working in a browser.

Cas

I think this general approach is a good one. It is too bad the Java Plug-In doesn't simply share the Java Web Start jar cache though I think this is a targeted feature for Dolphin. I think it should be possible to write a JOGLApplet or LWJGLApplet class which would be bundled in with the signed JOGL or LWJGL jar file which would allow unsigned applets which subclass these classes to be unsigned. The target applet could be passed as a command-line parameter to the JOGLApplet or LWJGLApplet class which (being signed) could then manually download and execute the target applet in a new class loader. Maintaining proper security for the target applet might be an issue. I think this would be a pretty cool trick to work around the current limitations of the Plug-In. Cas, if you make any progress in this area please post about it.

Doing the installation from within an applet is not necessary, at least not for me. I am satisfied if the applet simply detects the absence of the necessary files, then directs the user to a site where the user can download and execute an easy-to-use program that will install those files under his/her full supervision. After all, the installation only has to be done once, after which all applets will run without a hitch.

Doing the installation from within an applet is not necessary, at least not for me. I am satisfied if the applet simply detects the absence of the necessary files, then directs the user to a site where the user can download and execute an easy-to-use program that will install those files under his/her full supervision. After all, the installation only has to be done once, after which all applets will run without a hitch.

This involves dropping the appropriate jar files into the JRE, which is in general a really bad idea since it causes the same kind of "DLL hell" common on Windows. As a community we should probably come up with a solution that works equally well for JOGL and LWJGL as Cas and I suggested above.

It's pretty tricky to do what's required inside the context of a browser but not impossible. The steps involved are thusly:

1. You must have a fully signed applet.2. The applet, on first run, needs to create a directory in some well-known but interference-proof location. I would recommend ${user.home}/appletname/native.3. The DLLs are copied into there from their source jars4. The Java-side code needs to be able to call System.loadLibrary(System.getProperty("user.home")+"/"+appletname+"/"+native+"/jogl.dll") or something. Therefore JOGL (and LWJGL) would need a few subtle adjustments to allow them to load from custom paths.

It's not actually all that ugly a solution. I plan to try something along these lines myself to get Ultratron working in a browser.

Cas

I think this general approach is a good one. It is too bad the Java Plug-In doesn't simply share the Java Web Start jar cache though I think this is a targeted feature for Dolphin. I think it should be possible to write a JOGLApplet or LWJGLApplet class which would be bundled in with the signed JOGL or LWJGL jar file which would allow unsigned applets which subclass these classes to be unsigned. The target applet could be passed as a command-line parameter to the JOGLApplet or LWJGLApplet class which (being signed) could then manually download and execute the target applet in a new class loader. Maintaining proper security for the target applet might be an issue. I think this would be a pretty cool trick to work around the current limitations of the Plug-In. Cas, if you make any progress in this area please post about it.

This would be great ! I'm currently implementing this opengl software renderer of mine only to overcome the limitations of applet deployment... I'm going to check this stuff on windows and mac (I'll try it with the "old" JOGL 1.1.1 code base) and I'll keep you posted on that thread.

Even better !! I've just splited the signed jars in two (signed launcher/ unsigned sub-applet) and guess what ? everything works as expected !

I mean, the security checks are still valid on that unsigned jar (System.setProperty() on that side throws a security exception) and the sub-applet is yet able to create a GLCanvas and invoke open gl from that untrusted side !! There's no need to add a new classloader/security manager.

So with a little refinement, this launcher applet could be part of JOGL (or LWJGL) and benefit from the more trusted Sun certificate...

I'll improve a little bit and post the code (still waiting for other testers...)

Soory to report, the "jogltest" applet did not load for me ( Windows XP). The Java console reported the following errors:

Exception in thread "AWT-EventQueue-4" java.lang.UnsatisfiedLinkError: JAWT_GetAWT0 at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT0(Native Method) at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT(JAWTFactory.java:37) at net.java.games.jogl.impl.windows.WindowsGLContext.getJAWT(WindowsGLContext.java:282) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.lockSurface(WindowsOnscreenGLContext.java:167) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:126) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:248) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76) at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:236) at net.java.games.jogl.GLCanvas.display(GLCanvas.java:77) at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:86) at sun.awt.RepaintArea.paintComponent(Unknown Source) at sun.awt.RepaintArea.paint(Unknown Source) at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)stopstopdestroydestroyapplet installer initstarting installerstarted!applet installer async refresh loading lib C:\Documents and Settings\moyerc\.jogl_ext\1.1.1\jogl.dllJOGL STARTException in thread "AWT-EventQueue-5" java.lang.UnsatisfiedLinkError: JAWT_GetAWT0 at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT0(Native Method) at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT(JAWTFactory.java:37) at net.java.games.jogl.impl.windows.WindowsGLContext.getJAWT(WindowsGLContext.java:282) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.lockSurface(WindowsOnscreenGLContext.java:167) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:126) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:248) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76) at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:236) at net.java.games.jogl.GLCanvas.display(GLCanvas.java:77) at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:86) at sun.awt.RepaintArea.paintComponent(Unknown Source) at sun.awt.RepaintArea.paint(Unknown Source) at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)Exception in thread "AWT-EventQueue-5" java.lang.UnsatisfiedLinkError: JAWT_GetAWT0 at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT0(Native Method) at net.java.games.jogl.impl.JAWTFactory.JAWT_GetAWT(JAWTFactory.java:37) at net.java.games.jogl.impl.windows.WindowsGLContext.getJAWT(WindowsGLContext.java:282) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.lockSurface(WindowsOnscreenGLContext.java:167) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:126) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:248) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76) at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:236) at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:133) at java.awt.Component.setBounds(Unknown Source) at java.awt.BorderLayout.layoutContainer(Unknown Source) at java.awt.Container.layout(Unknown Source) at java.awt.Container.doLayout(Unknown Source) at java.awt.Container.validateTree(Unknown Source) at java.awt.Container.validate(Unknown Source) at joglapplet.JOGLAppletInstaller.joglStart(JOGLAppletInstaller.java:165) at joglapplet.JOGLAppletInstaller$2.run(JOGLAppletInstaller.java:134) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)

Fantastic work! Works well on Windows XP SP1 with 1.5.0_02, on Linux with 1.4.2, and on Mac OS X with 1.4.2. On Linux closing the applet seems to cause the browser to exit though this could be a bug in Mozilla (I'm running an ancient pre-1.0 copy on that machine).

Would you be willing to contribute this to the community under the BSD license?

So now what's the next step Ken ? Will this applet (or an updated form) be added to the jogl.jar in the near future ? That would resolve the whole signing issue and deployement for simple yet powerful applet games...

So now what's the next step Ken ? Will this applet (or an updated form) be added to the jogl.jar in the near future ? That would resolve the whole signing issue and deployement for simple yet powerful applet games...

Could you please sign and fax in the Contributor Agreement linked to from the JOGL home page? I'll PM you the fax number.

Once that's done we'll be glad to include this in the standard JOGL distribution. I think it will be fantastic to be able to run JOGL-based applets with no separate installation step necessary (and without interfering with other installations...). We may need some internal security review of the code, etc.

This reply is in regard to my earlier post of Nov. 4, reporting that I was unable to load the jogltest applet (unsatisfied link error...). It seems the problem stemmed from my placing the Jogl files in the JRE directories. After removing them, the applet launched sucessfully. This same problem may be confounding other users, since I am sure I am not the only one guilty of putting Jogl files in the JRE.

I'd also like to take this opportunity to thank everyone responsible for this breakthrough, especially Lilian. I am amazed at how quickly the Jogl community responded with an elegant solution to this vexing problem. Congratulations, and keep up the good work!

This reply is in regard to my earlier post of Nov. 4, reporting that I was unable to load the jogltest applet (unsatisfied link error...). It seems the problem stemmed from my placing the Jogl files in the JRE directories. After removing them, the applet launched sucessfully. This same problem may be confounding other users, since I am sure I am not the only one guilty of putting Jogl files in the JRE.

I'd also like to take this opportunity to thank everyone responsible for this breakthrough, especially Lilian. I am amazed at how quickly the Jogl community responded with an elegant solution to this vexing problem. Congratulations, and keep up the good work!

Thanks ! and great news ! Seems like we'll need to have a "troubleshooting installation" specific to this applet somewhere easily reachable...

There is however still a security issue I'm trying to fix : currently the native libraries are downloaded and installed from the signed part of the applet, but there is nothing granting the native libs are themselves properly signed. So someone could replace them with custom malicious code and bypass the sandbox security.

There are two ways of solving this problem : 1) - adding the native*jars properly signed in the archive list of the applet (that will increase the download size of 200/300kb), and adding the installer code in these jar files. That way, the installation will occur only through safe code/signed jar, it's certainly the easiest way. 2) - implementing the verification of the native jar files from the applet installer.

[edit] I'm not trying the 2) part, too much work... I'd rather use the integrated jar verification provided by 1). Stay tuned, more on this today.

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