Inside Swing: Event Processing

Many developers just call Window#setVisible(true) and do not think about magic that processed inside. But at one moment for me start really interesting how this magic still works. After some hours of debug I receive next picture.

General View

Environment: JDK 1.7.0_06
Let's code simple window program.

As we see - after call setVisible(true), creates two threads.

1. AWT-Windows thread mostly work in native code and is responsible on posting OS events to queue
2. java.awt.EventQueue - structure that responsible on storing and correct transfer of event objects between threads
3. AWT-EventQueue thread responsible on dispatching of events, and sending event to target components

Target Component Resolving

In this part - we investigate how Java decide which component is target for event. 

According our goal in Swing exists 2 types of widgets:

1. AWT Component (native components that registered in java.awt.Toolkit). Resolving of such components occurs in native code at AWT-Windows thread.

2. Swing Component (draws over AWT components). Resolving of its components occurs directly in Swing code and relies on component coordinates.

In this example - JFrame create and register native java.awt.Frame component. And also it contains JButton.

As may see component resolving occurs in 4 steps -
1. AWT-Windows thread set target as near AWT component and send such event to queue
2. Queue dispatch this event to specified AWT component
3. AWT component (related to JFrame) try to resolve target Swing component using event coordinates
4. After that event sends to really target Swing component

Performance

Problem in such solution that all occured events will be dispatched and sent to target component even such component do not have listeners for it. This behaviour overload ui thread and provide much unneeded computations. But for many application I think such performance is acceptable.