JDK-6625747 : Unix port needs knowledge of availability and default value of XToolkit
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-11-05
  • Updated: 2010-09-08
  • Resolved: 2008-07-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b09Fixed
Related Reports
Relates :  
JDK-6635826 - New plug-in does not run on top of JDK 1.4.2 because of System.getenv() use and other reasons
Relates :  
JDK-6522374 - XEmbeddedFrame doesn't reconfigure itself on ConfigureNotify
Description
The Unix port of the new Java Plug-In needs knowledge of the fact that the XToolkit is not the default in JDK 5 on Solaris platforms and to specify -Dawt.toolkit=sun.awt.X11.XToolkit. Currently it will attempt to always instantiate an XEmbeddedFrame and fail with the following stack trace:

java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
	at sun.plugin2.main.client.PluginMain.createEmbeddedFrame(Unknown Source)
	at sun.plugin2.main.client.PluginMain.access$100(Unknown Source)
	at sun.plugin2.main.client.PluginMain$1.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Caused by: java.lang.ClassCastException: sun.awt.motif.MToolkit
	at sun.awt.X11.XEmbeddedFrame.<init>(XEmbeddedFrame.java:31)
	... 14 more

Additionally, the new plug-in needs to understand that the XToolkit is not available in 1.4.2 and probably forbid the usage of that platform with the multiple JRE selection functionality. Either that or the XEmbed fixes to the MToolkit that appear in JDK 5 need to be backported to the 1.4.2 train, and the new plug-in modified to use an MEmbeddedFrame instead of an XEmbeddedFrame when the MToolkit is in use.
Comments
EVALUATION The new plug-in requires the AWT XToolkit, which was introduced in JDK 5, to be used on X11 platforms. On Linux in JDK 5, the XToolkit was made the default toolkit. However, on Solaris in JDK 5, for "compatibility" reasons, the MToolkit was left the default. The XToolkit became the default on Solaris platforms in JDK 6. In order to make the new plug-in's multiple JRE capability work with JDK 5 on Solaris, -Dawt.toolkit=sun.awt.X11.XToolkit must be specified on the command line of the launched subordinate JVM. Additionally, JREs before version 5, which don't work at all with the new plug-in since the XToolkit doesn't exist, are now filtered out of the available set on Unix/X11 platforms. JREs before version 1.4 are filtered out on all platforms, since the new plug-in by design requires 1.4. The regression test for this bug uncovered a deeper robustness issue where this failure mode would hang the browser if a LiveConnect call was made against the applet for which we failed to create an EmbeddedFrame. Added notification of this error down the stack to the Applet2Manager and LiveConnectSupport classes on the client side. Additional testing with 1.4.2 uncovered another problem where the usage of System.getenv() for debugging purposes was preventing the new plug-in from launching at all on that family, since System.getenv() was deliberately broken in an early JRE release (my personal experience was that this occurred in 1.2, but I can't confirm this from our sources) and only re-enabled in JRE 5. A separate bug, 6635826, has been filed to track this problem.
01-12-2007
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6625747.0 testcase: http://web-east.east.sun.com/deployment/www/tests/1.6.0_10/6625747/
01-12-2007