A DESCRIPTION OF THE REQUEST :
Unify the two threads. This will lead to a more maintainable and debuggable JDK. Most importantly, however, it will greatly improve the *perceived performance* of Swing and AWT, ceasing any debate versus rival technologies such as SWT.

JUSTIFICATION :
SWT is rising in popularity. Citing poorer perceived performance, Swing and AWT have started to fall behind. It's not just an empty threat; my own current project is SWT, much to my own objections to the contrary.

Having now worked extensively in both environments, and having worked on the internals of AWT, I have come to the conclusion that the only area of perceived performance where SWT can brag about being the leading edge of response time is having a unified thread for event dispatching that is synonymous with the windows thread. SWT brags one step further, citing it can do what 4638307 does, which is allow the user to manage that thread (whether that management actually is necessary remains to be seen, as 100% of the SWT programs I've seen do the exact same thing in their event loop anyway).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Better: maintainability, debuggability, and performance. There should only be one thread for the AWT : the AWT event dispatch thread.

In theory, it does not seem difficult to wrap the AWT event objects as windows events and use windows to post or read the events.
ACTUAL -
There is a lag in communicating between the two threads. Furthermore, having the two threads has been a source of deadlocks in 2D and AWT.

---------- BEGIN SOURCE ----------
Run any AWT or Swing program, pause it in a debugger, and count the number of threads. The number is 2.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The JDK can be run as-is, though the debate will continue and SWT will continue to gain popularity. Eliminate any source of perceived performance problems!
###@###.### 2005-04-04 05:45:47 GMT