Bug ID: JDK-4152133 Win32 peers should never call user code on the AWT-Windows thread

Versions (Unresolved/Resolved/Fixed)

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.

Other
1.2.0 1.2fcsFixed

In the following instances, it's possible for user code to be called by the
AWT-Windows thread, which runs the native message pump.  Errant user code
could then lock up the entire AWT toolkit for the whole Java VM.

	WButtonPeer.handleAction calls Button.getActionCommand
	WCheckboxMenuItemPeer.handleAction calls CheckboxMenuItem.setState
	WCheckboxMenuItemPeer.handleAction calls CheckboxMenuItem.getLabel
	WCheckboxPeer.handleAction calls Checkbox.setState
	WCheckboxPeer.handleAction calls Checkbox.getLabel
	WChoicePeer.handleAction calls Choice.select
	WChoicePeer.handleAction calls Choice.getItem
	WDialogPeer.setDefaultColor calls Dialog.setBackground
	WFileDialogPeer.handleSelected calls FileDialog.setFile
	WFileDialogPeer.handleSelected calls FileDialog.setDirectory
	WFileDialogPeer.handleSelected calls FileDialog.setVisible
	WFileDialogPeer.handleCancel calls FileDialog.setFile
	WFileDialogPeer.handleCancel calls FileDialog.setVisible
	WListPeer.handleAction calls List.select
	WListPeer.handleAction calls List.getItem
	WMenuItemPeer.handleAction calls MenuItem.getActionCommand
	WScrollPanePeer.scrolledVertical calls ScrollPane.getVAdjustable
	WScrollPanePeer.scrolledHorizontal calls ScrollPane.getHAdjustable
	WScrollbarPeer.lineUp calls Scrollbar.setValue
	WScrollbarPeer.lineDown calls Scrollbar.setValue
	WScrollbarPeer.pageUp calls Scrollbar.setValue
	WScrollbarPeer.pageDown calls Scrollbar.setValue
	WScrollbarPeer.dragAbsolute calls Scrollbar.setValue

I doubt this list is 100% complete, but these cases will
cause major problems when multiple AppContexts are in use.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2fcs INTEGRATED IN: 1.2fcs

14-06-2004

EVALUATION Implemented changes and added helper code to sun.awt.SunToolkit fred.ecks@Eng 1998-07-28 The original changes introduced two new race conditions: * Since a portion of FileDialog.show now executed asynchronously, client code could no longer assume that calls to getFile and getDirectory immediately after a show would return the correct values. Since the callback functions in WFileDialogPeer were never executed on the Windows thread anyways, the new functionality was backed out to correct the problem. * Since all user code is now executed on the EventQueue, parameters passed to the callback functions could be invalid by the time the InvocationEvent is dispatched and the code executed. To correct the problem, SunToolkit now posts MagicEvents to the PostEventQueue instead of InvocationEvents. MagicEvents are detected with an instanceof check in java.awt.EventQueue.postEvent. They add an ored string of values (flags) to an InvocationEvent. Currently, the only flag is PRIORITY_EVENT. Priority events are posted in front of standard events, although they are not posted in front of other priority events. This seemed to correct (or at least reduce the likelihood of) the race condition. david.mendenhall@eng 1998-07-31

31-07-1998

Relates :	JDK-4152184 - Motif peers should never call user code on the AWT-Motif thread
Relates :	JDK-4142012 - 1.2 Beta 4: Multiple AWT event queues not supported
Relates :	JDK-4142011 - 1.2 Beta 4: Multiple AppContext objects not supported
Relates :	JDK-4160289 - Win32 native code should never call client code on the AWT-Windows thread