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.