United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6625747 Unix port needs knowledge of availability and default value of XToolkit
JDK-6625747 : Unix port needs knowledge of availability and default value of XToolkit

Details
Type:
Bug
Submit Date:
2007-11-05
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-07-14
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b09)

Related Reports
Relates:
Relates:

Sub Tasks

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
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/
                                     
2007-12-01
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.
                                     
2007-12-01



Hardware and Software, Engineered to Work Together