Mac OS Java Update ( 1.6.0_20) breaks JOGL applets

Hi all, sorry if this is not the right place for this and the fact that it is a cross-post from any place I know that uses JOGL but here is the original post I made.



Hi all,



It seems that the latest Mac OS Java update break JOGL applets, which our product (JME based) uses :(.

On this site in fact you can see the applets no longer work if you just installed the latest release from Apple…



More than just posting the news, I will try to give some info to help with sorting this mess out :slight_smile:

I will attempt to open page:

http://jogamp.org/jogl-demos/www/applettest-jnlp.html



First off, when going to the applet a new (at least for Mac users) dialog pops up, the "Welcome to the Java Extension Installer".  Yikes! This just about scares my users out of their pants, as before the JNLP-applet process was as clean as a Flash app, no dialog, no install, just run. OUCH.



Second, after clicking though that dialog, it say "error" in the applet due to security issues and the console has this dump:

ava.lang.reflect.InvocationTargetException

        at com.sun.deploy.util.DeployAWTUtil.invokeAndWait(DeployAWTUtil.java:116)

        at sun.plugin2.applet.Plugin2Manager.runOnEDT(Plugin2Manager.java:3415)

        at sun.plugin2.applet.Plugin2Manager.createApplet(Plugin2Manager.java:2967)

        at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1444)

        at java.lang.Thread.run(Thread.java:637)

Caused by: java.lang.SecurityException: attempted to open sandboxed jar http://jogamp.org/deployment/webstart/jogl.all.cdc.jar as a Trusted-Library

        at com.sun.deploy.security.CPCallbackHandler$ParentElement.checkResource(CPCallbackHandler.java:354)

        at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(DeployURLClassPath.java:790)

        at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(DeployURLClassPath.java:980)

        at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(DeployURLClassPath.java:896)

        at com.sun.deploy.security.DeployURLClassPath.getResource(DeployURLClassPath.java:231)

        at sun.plugin2.applet.Plugin2ClassLoader$2.run(Plugin2ClassLoader.java:796)

        at java.security.AccessController.doPrivileged(Native Method)

        at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Plugin2ClassLoader.java:785)

        at sun.plugin2.applet.JNLP2ClassLoader.findClass(JNLP2ClassLoader.java:317)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:296)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

        at java.lang.Class.getDeclaredConstructors0(Native Method)

        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)

        at java.lang.Class.getConstructor0(Class.java:2699)

        at java.lang.Class.newInstance0(Class.java:326)

        at java.lang.Class.newInstance(Class.java:308)

        at sun.plugin2.applet.Plugin2Manager$12.run(Plugin2Manager.java:2955)

        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)

        at java.awt.EventQueue.dispatchEvent(EventQueue.java:633)

        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)

        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)

        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)

        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)

        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)

        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Exception: java.lang.reflect.InvocationTargetException



3) After going into Java Preferences, setting "Run Applets: In their own process" and under ADVANCED tab setting security to "Disable - insecure, not recommended" and rerunning, we now get this:



VALIDATE: libjogl_cg.jnilib

java.io.IOException: Cannot validate certificate for libjogl_cg.jnilib

        at org.jdesktop.applet.util.JNLPAppletLauncher.validateCertificates(JNLPAppletLauncher.java:1815)

        at org.jdesktop.applet.util.JNLPAppletLauncher.processNativeJar(JNLPAppletLauncher.java:1579)

        at org.jdesktop.applet.util.JNLPAppletLauncher.initResources(JNLPAppletLauncher.java:1350)

        at org.jdesktop.applet.util.JNLPAppletLauncher.initAndStartApplet(JNLPAppletLauncher.java:1254)

        at org.jdesktop.applet.util.JNLPAppletLauncher.access$000(JNLPAppletLauncher.java:658)

        at org.jdesktop.applet.util.JNLPAppletLauncher$1.run(JNLPAppletLauncher.java:907)

May 18, 2010 8:10:31 PM org.jdesktop.applet.util.JNLPAppletLauncher displayError

SEVERE: java.io.IOException: Cannot validate certificate for libjogl_cg.jnilib



I hope you can reproduce this, and I hope this is the right place to post this kind of thing!

Thanks for any help.



Shawn Kendall

IMILabs

This is a known issue, update 18-20 of Java increased restrictions on Java applets, so you can no longer run signed and unsigned code at the same time. I don't know about JOGL, but release 2.4.2 of LWJGL includes a special "AppletLoader" that is capable of running a jME applet without these issues. I am guessing JOGL also has something similar.

That is NOT the main issue (although it was one)



Native render canvas are forced off-screen by the new Mac Java update.

If you try running any JME applet after the latest Java update you'll see.



Here's some more info on it over at LWJGL and JOG

http://www.javagaming.org/index.php/topic,22167.0.html

http://www.javagaming.org/index.php/topic,22445.0.html



This is non-trivial, check the situation carefully again. :frowning:

Can you try this:

http://www.jmonkeyengine.com/applet/



It uses the LWJGL AppletLoader using the deployJava script provided by Sun.

So far it worked on all platforms tried.

Actually its only me. normen and ruth have macs and can test it.

It seems that there isn't much we can do though, right? Just complain to Apple?

ShawnKendall said:

it's a JOGL/LWJGL issue ultimately.

uh, we had stuff that worked ... it works on all other platforms, even u20.

Apple made a change that a) broke the whole Trusted-Library b) changed the architecture completely to only have off screen rendering.

a) is the main problem
b) is going to be a performance issue

I am not sure how we can fix a, but we might find a workaround. b is going to be a nightmare to fix ...
ShawnKendall said:

I'm guessing nobody on the dev team has a Mac to test with, because all you would have to do is load the page to see the issue...

..and update the OS before, which I dont do blindly on my development machine because of issues like these ;)

I will update and dig more into this but you are right, ultimately its a lwjgl/jogl issue.
Hope you keep us updated through this thread, we will, too.

Cheers,
Normen

Okay, I can run the applet at http://www.jmonkeyengine.com/applet/ just fine, no problems with 1.6.0_20 on MacOSX 10.6.3 for me, but I have to add that I have a 32bit Intel Mac and thus run the 32bit version of Java 1.6.0_20 here. I will test tomorrow at work on a 64bit Intel Mac.



Cheers,

Normen

normen said:

..and update the OS before, which I dont do blindly on my development machine because of issues like these ;)


Really, spoken like a true developer....
Unfortunately, our users will (and should) do security updates when they come out.  If only they would just update when WE say it's ok? ;)

WRT "Okay, I can run the applet at http://www.jmonkeyengine.com/applet/ just fine"
Try running with the Mac Java Preferences
"Run Applets: [X] In their own process"
That has been the recommended setting for native apps, so us and our users have that set but also I suspect that this is why it fails in Chrome as well, Chrome tabs are all in separate processes anyway.
ShawnKendall said:

WRT "Okay, I can run the applet at http://www.jmonkeyengine.com/applet/ just fine"
Try running with the Mac Java Preferences
"Run Applets: [X] In their own process"
That has been the recommended setting for native apps, so us and our users have that set but also I suspect that this is why it fails in Chrome as well, Chrome tabs are all in separate processes anyway.


Okay, like this the applet does not work for me as well..

I dont know what the american version of OSX says, but my german version clearly states (under the "in browser process") "standard, higher compatibility". So to me the "own process" thing is not the recommended setting but rather a "beta" test of some multithreaded approach to java applet running, at least in Safari.. And it apparently does not work very well ;)..

I think this should be the concern of not only the lwjgl/jogl teams but also of Oracle and the browser developers actually...

Cheers,
Normen

I can confirm this, in Chrome just shows a blank screen, in Safari it works… as long its running inside the browser process…

the problem with running jogl/lwjgl as an applet is Apple's fault. The apple engineers are aware of it and say they are working to get it to work again.

I don't have a mac so i can't test this but what happens if you try to load an applet that uses a GLJPanel?

pgi said:

I don't have a mac so i can't test this but what happens if you try to load an applet that uses a GLJPanel?


The problem is if you select out of process applets the java plugin2 is used otherwise java plugin1. Java plugin1 continues to work fine.

However with java plugin2, Apple have tried to integrate java applets better into the web page, what they do is render everything offscreen, then draw it on the web page with their CoreGraphics rendering framework. This allows for other html components to overlap the applet and help better integrate the applet into the web page. Although a nice attempt the downside is that stuff like lwjgl/jogl can no longer attach their stuff by grabbing a pointer to an under lying window (as there is no window anymore). Thus even if you use GLJPanel it still won't work and even if it did it would have a big performance hit.

I asked because GLJPanel uses an offscreen buffer to do the rendering so i thought things were different with that kind of backend. If it worked then one could write a jme2-gljpanel canvas.

interesting, well if someone does give it a try, be nice if they can report back with their results.