OK so it seems there is a certificate Sun can use to push native libraries to the client without a security popup. We’d rather like to get ahold of that certificate for LWJGL. What’s the score?
Cas 
I wonder how they decide who gets to use that special cert. Seems a bit unfair if one GL binding can and another can not… :
I’m going to predict an exchange something like this:
LWJGL: “Can we use your magic certificate please?”
Sun: “No.”
Perhaps there’ll be some kind of verification process for which libs can be submitted in order to use Sun’s certificate, but it’ll be slow and expensive.
It is interesting that they’ve done this for JOGL though, as it exposes huge globs of native code (that Sun has no control over) directly to malicious applet writers. It’s going to be difficult to explain to an irate user that his pwned machine is the fault of his vulnerable graphics driver and not the invisible applet that accessed it.
Is the behavior of JMonkeyEngine programmers fair? JME 2 pretends to support JOGL but when some bugs are found in the JOGL renderer, it is not considered as important as bugs in the LWJGL renderer. “Charité bien ordonnée commence par soi-même” -> before complaining about Sun’s behavior, some people should teach their own lessons to themselves. Remind me who wrote the JOGL renderer of Ardor3D please.
It would be the same if LWJGL was able to benefit of this certificate and some people would program applets with it. If you really think Sun should not use this kind of certificate because it exposes huge globs of not controlled native code to malicious applet writers and if you are coherent, you won’t wish that LWJGL benefits of it neither.
I agree with your analysis of your hallucination of my position.
:-
Is this just a language barrier, or are you really this angry all the time?
Um… ok? As I recall, Steve Vaughan over at SRA wrote what he needed of a Jogl port and donated it. Very nice of him to do that too. Not sure why you have this chip on your shoulder, but personally I’ve never claimed it was a complete drop in replacement for jME’s lwjgl impl. I think they’ve improved it some since I left jME last year though.
A while ago there was discussion within Sun about the possibility of signing third-party code that had been suitably audited. I’ll ask one of the members of the Java security team to look at this thread and comment.
For what it’s worth, I personally have no desire to put JOGL at an unfair advantage or LWJGL at an unfair disadvantage.
It’d be nice to fast-track it seeing as we’ve been on about it for, oooh, years 
Cas
I’m sure the LWJGL team will be happy to make any security changes needed to get it approved too.
I believe it’s already watertight.
Cas
Hello all together,
for a few weeks I get the following message when starting my applet:
java.io.IOException: Cannot validate certificate for jogl.dll
java.io.IOException: Cannot validate certificate for gluegen-rt.dll
Now I read this topic but I don’t now, what to do. Is there an update? Which jnlp-File I have to call up?
Are you using local copies of the files? if so re download them or use the one hosted by sun.
Otherwise post your jnlp file.
In my PHP-file I’m using this code:
<applet id="test" name="test" mayscript code="org.jdesktop.applet.util.JNLPAppletLauncher" width=743 height=558 archive="applet-launcher.jar, test.jar">
<param name="codebase_lookup" value="false" />
<param name="subapplet.classname" value="gov.nasa.worldwind.examples.applet.TestApplet" />
<param name="subapplet.displayname" value="Test" />
<param name="noddraw.check" value="true" />
<param name="progressbar" value="true" />
<param name="jnlpNumExtensions" value="1" />
<param name="jnlpExtension1" value="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />
</applet>
I also deleted the cached files.
But: In my test.jar, there is a jogl.jar and gluegen-rt.jar included (I created a Fat Jar with Eclipse).
Could it be, that the error is from these files? If yes, where can I get the new files with new certificates?
But offline in Eclipse it works. And when I delete the extension parameters of my applet code, I get a message if I want to disable Java’s DirectDraw. If I click on “Yes”, I get a message “Unable to open properties file” and there it ends. It doesn’t work.
Oh, a fat jar? That isn’t necessary. Go back to the example they use at the applet launcher page and all will work splendidly for ya.
https://applet-launcher.dev.java.net/
If you really want to use a fat jar you need to redownload the applet launcher, jogl and gluegen jars.
Thanks! That part works now. But another not… I can create my Jar (Fat Jar as well) but when trying to start it, I get the following messages:
java.lang.NoClassDefFoundError: Could not initialize class gov.nasa.worldwind.WorldWind
at gov.nasa.worldwind.examples.applet.TestApplet.stop(TestApplet.java:326)
at org.jdesktop.applet.util.JNLPAppletLauncher.stop(JNLPAppletLauncher.java:927)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
JNLPAppletLauncher: static initializer
os.name = windows xp
nativePrefix = nativeSuffix = .dll
tmpRootDir = C:\DOKUME~1\CHRIST~1\LOKALE~1\Temp\jnlp-applet\jln118218448536438533
Applet.init
subapplet.classname = gov.nasa.worldwind.examples.applet.TestApplet
subapplet.displayname = Test
Applet.start
os.name = windows xp
os.arch = x86
processNativeJar: using previously cached: C:\Dokumente und Einstellungen\[My Name]\.jnlp-applet\cache\localhost\01182800353d4550f1a3d260703eb7074a5def1b\jogl-natives-windows-i586.jar
validateCertificates:
VALIDATE: jogl.dll
VALIDATE: jogl_awt.dll
VALIDATE: jogl_cg.dll
extractNativeLibs:
EXTRACT: jogl.dll(jogl)
EXTRACT: jogl_awt.dll(jogl_awt)
EXTRACT: jogl_cg.dll(jogl_cg)
processNativeJar: using previously cached: C:\Dokumente und Einstellungen\[My Name]\.jnlp-applet\cache\localhost\01182800353d4550f1a3d260703eb7074a5def1b\gluegen-rt-natives-windows-i586.jar
validateCertificates:
VALIDATE: gluegen-rt.dll
extractNativeLibs:
EXTRACT: gluegen-rt.dll(gluegen-rt)
JNLPAppletLauncher.loadLibrary("jogl")
loading: C:\DOKUME~1\CHRIST~1\LOKALE~1\Temp\jnlp-applet\jln118218448536438533\jln6693041931166781508\jogl.dll
java.lang.ExceptionInInitializerError
at gov.nasa.worldwind.WorldWind.createConfigurationComponent(WorldWind.java:178)
at gov.nasa.worldwind.WorldWind.initialize(WorldWind.java:43)
at gov.nasa.worldwind.WorldWind.<init>(WorldWind.java:37)
at gov.nasa.worldwind.WorldWind.<clinit>(WorldWind.java:26)
at gov.nasa.worldwind.awt.WorldWindowGLCanvas.<init>(WorldWindowGLCanvas.java:55)
at gov.nasa.worldwind.examples.applet.TestApplet.init(TestApplet.java:244)
at org.jdesktop.applet.util.JNLPAppletLauncher.startSubApplet(JNLPAppletLauncher.java:1929)
at org.jdesktop.applet.util.JNLPAppletLauncher.access$200(JNLPAppletLauncher.java:658)
at org.jdesktop.applet.util.JNLPAppletLauncher$5.run(JNLPAppletLauncher.java:1269)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(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)
Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission gov.nasa.worldwind.config.file read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at gov.nasa.worldwind.Configuration.initializeCustom(Configuration.java:88)
at gov.nasa.worldwind.Configuration.<init>(Configuration.java:46)
at gov.nasa.worldwind.Configuration.<clinit>(Configuration.java:34)
... 17 more
I tested the new applet call up code with the old Fat Jar (with old jogl.dll and gluegen-rt.dll) and that works perfect.
<applet id="test" name="test" mayscript code="org.jdesktop.applet.util.JNLPAppletLauncher" width=743 height=558 archive="test.jar, http://download.java.net/media/applet-launcher/applet-launcher.jar, http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jar, http://download.java.net/media/gluegen/webstart/gluegen-rt.jar">
<param name="codebase_lookup" value="false" />
<param name="subapplet.classname" value="gov.nasa.worldwind.examples.applet.TestApplet" />
<param name="subapplet.displayname" value="Test" />
<param name="noddraw.check" value="true" />
<param name="progressbar" value="true" />
<param name="jnlpNumExtensions" value="1" />
<param name="jnlpExtension1" value=" http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />
</applet>
But I guess, that combination (Fat Jar with old certificates, new code [see above]) isn’t a good one…
The only thing I see is wrong is an extra space in the beginning of the jnlp path. Is the html code you posted the code you use without the fat jar as well?
Also, putting the dll’s into the jar isn’t adviced seeing as:
- They’ll be downloaded anyway by the applet launcher
- Even if they weren’t mac and linux and solaris and so on won’t be able to use the dll’s.
I deleted the extra space but that didn’t help.
Yep, I want to use this.
The problem is, that the old Fat Jar works, but the new one and the normal Jar not.
You could try to download the applet launcher jar and put it on your website to make sure what you’re calling from your main jar is on the same host as the initial jar, might help. Otherwise I don’t know, it never was an issue for me.
Thank you, for your help!
I posted my problem in a World Wind forum.
Maybe the guys there have an idea…
Works!
Something was wrong with my SignTool.
I signed the Jar manually and now it works!
Again: Thanks for helping with the JOGL certificate and for the applet hints!