With JRE 6u10 and old java plugin, the crash is due to we're trying to dereferencing a null java object in the native code. There's some security exception thrown at the java level causing the native plugin code fails to find the IExplorerPluginContext java class and creates a global ref. to the plugin object.
A potential fix in the old java plugin is to enclosed some java code within a doPrivileged block (see suggested fix for details). With the fix, there's a remaining AccessControlException triggered by the eclipse code from the testcase from CA.
The call stack of the AccessControlException in the main thread is as follows:
 java.security.AccessControlContext.checkPermission (null)
 java.security.AccessController.checkPermission (null)
 java.lang.SecurityManager.checkPermission (null)
 java.lang.SecurityManager.checkPackageAccess (null)
 sun.applet.AppletSecurity.checkPackageAccess (null)
 sun.misc.Launcher$AppClassLoader.loadClass (null)
 java.lang.ClassLoader.loadClass (null)
 java.lang.ClassLoader.loadClassInternal (null)
 org.eclipse.swt.internal.win32.OS.DispatchMessageW (native method)
 org.eclipse.swt.internal.win32.OS.DispatchMessage (OS.java:1,473)
 org.eclipse.swt.widgets.Display.readAndDispatch (Display.java:2,430)
 SimpleSwtBrowser.main (SimpleSwtBrowser.java:38)
Note that in order to load the old java plugin, one needs to set the following env. variable:
Our java plugin also requires the -Xbootclasspath to contain the deploy.jar, plugin.jar, and javaws.jar. Since the jvm is used to start the app. with an embedded browser and the jvm arguments can't be modified once it has been started, the script for starting the app. needs to be modified to the following:
java -cp %CLASSPATH% -Xbootclasspath/a:f:\progra~1\java\jre6\lib\deploy.jar;f:\progra~1\java\jre6\lib\plugin.jar;f:\progra~1\java\jre6\lib\javaws.jar -Djava.library.path=.;f:\progra~1\java\jre6\bin SimpleSwtBrowser
Attaching the testcase from CA with the startup script modified to the attachment.
The problem is due to a jvm is already in use for starting the app. (testcase) and then when the embedded IE tries to load an applet, it tries to reuse the same jvm and fails.
With the old plugin and loading an applet with the object tag, the failure is actually in CActivatorJNI::Initialize. The following fails with "ClassNotFound" error:
SmartJClassRef clazz(env, PLUGINPKG "JavaRunTime");
The above is basically doing a m_env->FindClass(name);
The m_env isn't NULL.
I've also tried setting CLASSPATH variable to include F:\progra~1\java\jre6\lib\plugin.jar but still got the same error.
With the old plugin and loading an applet with applet tag, it'll try to use the msvm. So it seems the TreatAs key is ignored in this scenario. The applet also fails to load with ClassNotFound error. The class is referring to the applet class in this case.
###@###.### said that in the context of the new Java Plug-In if we tried to make this work then it would be running the JVMManager recursively in the client attached JVM. We would need to modify JavaVM.c to handle the case where the JVM has already been created.