Abstract Window Toolkit Framework

Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About This Document

Purpose

This document introduces the AWT (Abstract Window Toolkit) framework delivered as part of the DRL (Dynamic Run-time Layer) initiative. This document focuses on the characteristics of the current AWT implementation.

Intended Audience

The target audience for the document includes a wide community of engineers interested in further work with AWT to contribute to its development. The document assumes that readers are familiar with AWT and the Java* programming language.

Documentation Conventions

This document uses the unified conventions for the DRL documentation kit.

Introduction to AWT

As indicated in the specification [1], the Abstract Window Toolkit (AWT) is a part of the Java* Foundation Classes (JFC). AWT provides basic facilities to develop graphical user interfaces (GUI) and to draw simple graphics for platform-independent applets and applications.

In AWT, GUI consists of components, such as buttons, menus, and top-level windows. One of the main AWT features is that all its built-in components are heavy-weight, that is, every Java* component has a native GUI object behind it. The Swing library [2] is built on the basis of AWT and uses light-weight components, which do not have the 1:1 mapping with native resources.

AWT in DRL

This document describes major design features and internal specifics of the DRL AWT implementation. Further in this document, AWT denotes the DRL implementation for convenience.
To summarize, DRL AWT has the following key features:

Event handling mechanism
Focus dispatching flow
AWT components' appearance handling in custom visual themes
Support for multi-threading

Event Handling

AWT helps applications react to user's actions and traces the system state and the AWT internal state by means of events. Subsequent sections describe the AWT event handling implementation in DRL with focus on the interaction between AWT and the native system, specifically, the GUI subsystem of OS. For information on application events handling, consult the AWT specification [1].

Native and AWT Events

The DRL AWT framework deals with the following types of events:

Native events generated by the operating system: XEvents on Linux* and Windows messages (MSG) on Windows*.
AWT events generated and handled by the AWT framework. All AWT events are subclasses of the AWTEvent class and are stored in the AWT event queue represented by the�EventQueue class.

Event Dispatch Thread

AWT has the event dispatch thread (EDT) at its basis, represented by the class�java.awt.EventDispatchThread. This thread handles all generated types of events by going over the loop shown in Figure 1. EDT starts on AWT Toolkit creation and stops on application termination.

AWT and native event handling order

Figure 1: Native and AWT Events Handling

In more detail, EDT performs the following event loop:

Wait for and get the native event from operating system.
Decode the native event into an AWT event.
Dispatch the AWT event: find the target AWT component for this event and pass it to this component through the�java.awt.Dispatcher class.
Push the AWT event to the event queue represented by the�java.awt.EventQueue class.
Pop all AWT events from the event queue.
Pass the given AWT events to the appropriate AWT component by using the�java.awt.Component.processXYZEvent() methods.
Call the appropriate AWT component’s event listeners of the EventListener interface. Applications should implement appropriate listeners' interfaces to react to specific events.

Native and AWT Events Priority

AWT events have a higher logical priority than native events.
EDT does not wait for a new native event or fetch a ready native event unless all existing AWT events have been handled.
After handling all AWT and native events, EDT waits for a new native event.
If a non-EDT thread generates an AWT event when EDT is waiting for a native event, a new native event is required to wake EDT and make it handle the AWT event. Every time a non-EDT thread adds an event to the queue, the method�awake() of the�NativeEventQueue interface is called. This method produces a native auxiliary event so that EDT becomes ready to handle AWT events. EDT treats this auxiliary event as invisible.

Native Events Handling

This section defines native events types and the way AWT handles these events based on their type.

Native Events Classification

Figure 3 below demonstrates how native events can be classified by their role in the AWT framework.

Native events: 4 subtypes

Figure 3: Native Events Classification

State events signify that a native object corresponding to an AWT object has changed its state. For example, when the user minimizes the window, the window state change native event is generated.
Events-signals indicate a sporadic occurrence in the OS, usually, caused by user's actions. For instance, the event caused by a mouse wheel rotation is signal information.
Invisible events do not cause AWT event generation and are used only to update the internal data structure.
Unused events are concerned to specific OS features that are not supported by AWT, so these events are ignored.

Abstracting the Native Platform

Native events handling goes in two stages: the first stage depends on the native platform, and the second stage is the same on all supported platforms. Platform-dependent functionality comprises the Window Toolkit, WTK, in the�org.apache.harmony.awt.wtk package. The platform-dependent and platform-independent levels cooperate via three main interfaces of this package:�NativeEventListener,�NativeEvent, and�NativeEventQueue, as shown in Figure 2. Classes implementing the�NativeEvent and�NativeEventQueue interfaces are platform-specific. For example, the�NativeEvent interface is implemented by the classes�LinuxEvent and�WinEvent for the Linux* and Windows* systems respectively.

Interfaces depending and not depending on the underlying platform

Figure 2: Interfaces for Abstracting the Native Platform

�

Classes of the�NativeEvent interface convert information about native events to a platform-independent format. The�NativeEventQueue interface fetches native events, and the�NativeEventListener interface of the Java* EDT thread handles native events. In the DRL AWT implementation, native and AWT events are handled by the single EDT thread. See the Multi-threading Support section for more information.

Native Event Dispatching

The method�onEvent() in the platform-dependent�NativeEventListener interface processes native events. Platform-dependent classes implementing�NativeEventQueue call this method to handle a relevant native event, see Figure 4.

AWT handles relevant native events by following these steps:

The platform-specific implementation of the�NativeEvent interface translates the event to a unified format described by the interface�NativeEvent.
The platform-specific implementation of�NativeEventQueue calls the EDT method�onEvent() and passes the decoded event as a parameter.
EDT passes the event to the�java.awt.Dispatcher class identifying the type of event.
Depending on the event type, the dispatcher can handle the event or transmit it to a specific sub-dispatcher. For example,�java.awt.MouseDispatcher works with mouse events,�java.awt.Dispatcher.KeyDispatcher processes keyboard events.

The result of native event dispatching depends on the event type: state event, signal or invisible. Signal native events are translated to AWT events explicitly (Figure 4, second column). For state and invisible events, the AWT framework updates the state of the AWT object corresponding to the native object that sent the event. For state events, this implicitly generates an AWT event signaling an AWT object state change (Figure 4, third column). For invisible events, the AWT object state gets updated silently (Figure 4, fourth column).

Native events handling by the 4 subtypes

Figure 4: Native Events Handling by Type

Native and AWT Event Handlers Cooperation

Native events often result in new AWT events that need to be handled. This section describes when and how AWT event handlers are called for this purpose.

The Windows* OS generates synchronous and asynchronous native events, so that AWT must be ready to handle nested calls to the event handler. In this case, AWT makes an additional effort to handle AWT events one by one. DRL AWT uses the�WindowProc event handler inside WTK for interaction with Windows*. The OS calls this handler for handling any native event in AWT.

The Linux* event handling mechanism is different with its own method for handling native events. In this OS, all native events are asynchronous and no nesting happens.

Handling a single event

Figure 5 is an example of mouse click event handling in AWT. In the given case, the AWT listener does not co-operate with the underlying native system, and, consequently, no other native events are produced during the listener's operation. The example demonstrates handling an event on Windows*.

Native events handling by the 4 subtypes

Figure 5: Mouse Click Event Handling

Numbers in the figure above correspond to the following steps in the event handling flow:

The OS calls�WindowProc to handle the native event. The type of event is determined, information about this event is gathered and passed to the�onEvent() method of�NativeEventListener.
The�java.awt.Dispatcher class finds the appropriate target for this event and posts an AWT event to the AWT event queue. In this example, it is�MouseEvent.
The method�onEventNestingEnd() is called to handle all accumulated AWT events.�MouseEvent is fetched from the event queue and finally dispatched. Listeners of the event's target are called at this point.
�WindowProc returns.

Handling nested events

Figure 6 is an example of mouse click event handling with the event listener requests keyboard focus on the clicked component.

Nested Event handling

Figure 6: Mouse Click Event Handling with a Nested Event

Numbers in the figure above correspond to the following steps in the event handling flow:

The OS calls�WindowProc, the native event is transformed into an AWT event and stored in the event queue.
The event listener calls�requestFocus(), which indirectly results in a native API call.
The OS calls�WindowProc to report the focus change event. Because the previous call to�WindowProc is not complete yet, the new call is recognized as nested.
The dispatcher adds another AWT event,�FocusEvent, to the event queue.
�WindowProc returns without handling AWT events because it is a nested native event handler.
The method�onEventNestingEnd() is still working in the first-level�WindowProc handler. This method fetches and dispatches the�FocusEvent added at step 4.
When the AWT event queue is empty,�WindowProc returns.

This technique guarantees that AWT event handlers are called sequentially. The nested native event handler does not attempt to handle pending AWT events. Instead, these events are collected in the event queue to be handled later. The first-level native event handler dispatches all the AWT events waiting in the queue.

Focus Subsystem

The AWT focus subsystem is a set of classes for managing keyboard input focus responsible for:

Interacting with the underlying native window system, such as�Win32 or�X11, by way of handling native focus events and making native focus requests
Synchronizing the focus state with the native focus state

In the DRL implementation, the focus subsystem functionality is distributed among several internal layers:

Window Toolkit (WTK) is a platform-dependent implementation of the abstract window toolkit. WTK directly interacts with the native window system via native library calls.
Focus Dispatcher is a platform-independent level of the focus subsystem closely asynchronously interacting with the window toolkit to respond to native focus events and provide this information to the AWT upper level.
AWT level is the major part of the focus subsystem working synchronously with the user application by generating and posting AWT events to the event queue.

The interaction between user code and these levels of the focus subsystem is shown on Figure 7 below.

Detailed event handling schema

Figure 7. Focus Event Data Flow

The following code entities perform the major focus subsystem tasks:

The�java.awt.FocusDispatcher class handles focus events received from the window toolkit level.
Package-private methods of the�KeyboardFocusManager class manage focus on the higher AWT level.

Subsequent sections describe the levels of focus management in more detail and give specifics of the DRL implementation compared to the focus specification [3].

Focus Dispatcher

The focus dispatcher responds to native focus events and, for those relevant to AWT, sends an internal focus change event to the higher AWT level. The dispatcher skips redundant native events and handles event proxying supported on certain native platforms. The focus dispatcher in DRL is characterized by the features listed below.

Platform independence

This component is platform-independent and handles native events in a unified way. For example, when set to skip a false event, the focus dispatcher does not change its behavior on platforms where this type of event never occurs.

Internal operation only: no interaction with user code

The dispatcher does not generate AWT events and never calls client code directly, synchronously. Instead, WTK passes event information to the upper AWT level, which includes the flag indicating whether the focus is lost or gained, the source and opposite components, and the focused window.

Focus Proxying

When the focus is on an inactive window, focus proxies are used. A focus proxy is a child of an active window that has the native focus, whereas focus and key events are redirected to the Java* focused window. This way, the native decorations indicating the active state of the window are on the active window. At the same time, keyboard input and focus AWT events go to the focused window, whereas the native focused window is the focus proxy. The focus dispatcher transfers the native focus to the focus proxy and back when necessary. Events are redirected by the keyboard focus manager.

Events and Output in Event Proxying

Figure 8. Focus Proxy

If the active window is the focused window, no proxying occurs. In this case, the nearest heavyweight ancestor of the focus owner or the focus owner native window itself (if focus owner is a heavy-weight component) has native focus.

AWT Level

The higher level of the focus subsystem generates and posts all necessary AWT events to the event queue. This level keeps track of the following focus states:

The focus state visible to the user and updated after the AWT event is dispatched by the keyboard focus manager, [3].
The low-level WTK focus state reported by the underlying WTK level and updated immediately on getting a native event.

The AWT level of the focus subsystem handles focus requests synchronously on every successful focus change request. When the method�requestFocus() is called, the keyboard focus manager posts all necessary AWT events in the required order irrespective of the success or failure of the native focus request. In other words, the AWT subsystem does not wait until the native focus request gets confirmed and the corresponding native events are received.

After receiving a notification from the native system, WTK requests the AWT level to update the focus state via an internal request. For example, if the native system reports an unsuccessful focus change, a component might lose focus.

Note

Only certain native focus-related events cause a Java* focus state update. For example:

When a top-level native window gains focus, the focus goes to a child of this window or the�Window component itself, in case no child elements are available.
When a window in another application gains focus, the focus dispatcher calls the�setFocus(false) method on the focus owner to clear the focus owner value.

DRL Focus Implementation Specifics

Below, the specific features of DRL implementation are listed compared to the focus specification grouped by their function.

Replacing the DefaultKeyboardFocusManager class: The keyboard focus manager handles all events in the required order and never synthesizes window activation events. Instead, the focus manager skips the events that do not correspond to the current focus state. Such events can be generated by the private API of this class in response to native events. For example, the keyboard focus manager ignores events sent to the window that has failed to become the focused window because the corresponding AWT event was dispatched and vetoed.
When handling the�WINDOW_GAINED_FOCUS event, private methods in the keyboard focus manager set focus on the appropriate child component of the window.
Programmatic Traversal: Disabling any ancestor of the focus owner, both light-weight and heavy-weight, automatically initiates a focus traversal.

Visual Themes in AWT

This document describes the mechanism of drawing standard AWT components with platform-independent Java* means or platform-specific native API or using both approaches.

Default theme

You can paint standard components in many ways, including drawing the component parts (text, background, shadows and all other elements) by the means of class�java.awt.Graphics. Note that the framework must not paint standard components by the method�java.awt.Component.paint() because it could be overridden. Instead, when processing a painting event, the framework calls the package-private method�java.awt.Component.prepaint() just before calling the method�paint(). The�prepaint() method does the actual painting for all standard components by delegating the painting task to the theme. This approach might not seem optimal, but it works on all supported platforms without any changes.

The�org.apache.harmony.awt.Theme class implements the default theme. Methods of this class do the following:

Paint standard components, for example, the method�drawButton().
Calculate the optimal component size for each type of component, for example, by using the method�calculateButton().

The default theme class is platform-independent, non-abstract and fully functional, and it usually works when the native theme is disabled or not available, or when the native theme re-uses functionality of the standard theme.

Derived themes

You can create a custom theme that inherits from the default theme and contains specific features. The current implementation contains the�WinTheme class that extends the default theme as shown in Figure 9.

To use the native API in your theme, extend the default theme overriding its painting methods. In the derived theme, you can use the additional features of specific implementation of the�Graphics class, and explicitly call native API functions via wrappers, see�org.apache.harmony.misc package for details. Figure 9 below demonstrates theme-related classes hierarchy with methods related to the�Button component as an example. A block of code for extending the�drawButton() method is shown in Example 1 below.

OS specific themes as subclasses to the major theme

Figure 9: Hierarchy of Theme Classes

�

After creating a derived theme, turn it on by using the property�awt.theme. This property contains the name of a subclass of default theme class used as the theme by all components. If the property points to a non-existent class or if the required native library is missing, or any other error occurs, the default theme is used. If the property is not set, the native theme of the current OS is used if it exists. If no OS theme exists, the default theme is used.

To force the default theme, set the command-line option�-Dawt.theme=0. As long as zero is an invalid class name, this does the job.

Implementation details

Painting standard components requires access to their internal state, such as the pressed state, the focused state, the background color, and the contained text. Because not all these attributes are visible through the public API, the DRL AWT module provides a set of interfaces to allow the theme to access private and public data. The package�org.apache.harmony.awt.state contains these interfaces, such as,�TextState,�CheckboxState, and�ButtonState. Each standard component class has an inner class that implements the appropriate interface and has the state field of that class declared. The�java.awt.Component class stores all functionality common for all types of standard components. Specifically, the�java.awt.Component class has an inner class�ComponentState that implements the�org.apache.harmony.awt.state.State interface. This inner class enables implementing the state of a specific component by overriding only a few methods.

Standard components delegate the painting and size calculation to the currently active theme and pass their state field value as a parameter to every method of the theme.

Platform-specific and component-specific code is concentrated in separate helper classes, such as�DefaultButton, the helper to the default theme, and�WinCheckbox, the helper to the Windows* theme. The theme class contains only simple methods.

Example 1

This is an example with the�Button component.

public void drawButton(Graphics g, ButtonState s) { 
    drawButtonBackground(g, s); 
    drawButtonText(g, s); 
} 
protected void drawButtonBackground(Graphics g, ButtonState s) { 
    DefaultButton.drawBackground(g, s); 
} 
protected void drawButtonText(Graphics g, ButtonState s) { 
    DefaultButton.drawText(g, s); 
}

When designing a custom theme, you may need to override some of these protected methods.

Figure 10 shows an example of component classes relation, inner states and the inheritance hierarchy of component state interfaces. The figure contains short names for convenience, for example, Component actually means java.awt.Component.

Methods and classes related to state change operations

Figure 10: Inheritance and Composition for Components' State

Using State Interfaces in a Standard Component

This section illustrates how the state interfaces are used in the�Button component. In DRL AWT, all standard components follow the same model.

This is a part of the�java.awt.Button code that illustrates how to use visual themes in standard components.

class State extends Component.ComponentState implements ButtonState { … } 
final transient State state = new State(); 
    
void prepaint(Graphics g) { 
    toolkit.theme.drawButton(g, state); 
}

The framework calls the�prepaint() method, which paints standard components. The painting itself is done by the theme class, and all the information it requires is contained in the state variable.

Windows* theme

In DRL, the Windows* theme is implemented by the class�org.apache.harmony.awt.theme.windows.WinTheme, which inherits from the class�org.apache.harmony.awt.Theme.

The�WinTheme class paints components using the Windows* API function�DrawFrameControl() in the classic mode and�DrawThemeBackground() in the XP mode, and basic Windows* API painting functions.

The implementation also includes several helper classes:

The class�org.apache.harmony.awt.gl.WinThemeGraphics has a set of native methods that call the Windows* API. This class is tightly coupled with�org.apache.harmony.awt.gl.WinGDIPGraphics2D, which is an implementation of�java.awt.Graphics. The�WinThemeGraphics class queries�WinGDIPGraphics2D for the current clip, translation and device context.
The class�org.apache.harmony.awt.wtk.windows.WinEventQueue.ThemeMap that handles theme-related native events and opens and closes handles of native theme data when needed.
The set of helper classes�org.apache.harmony.awt.wtk.theme.windows responsible for specific types of components, for example,�org.apache.harmony.awt.wtk.theme.windows.WinButton.

Note

If the Windows* theme does not support the combination of components attributes, it delegates painting to the default theme by calling the super class. For example, the default theme can be used when the background color of a push button differs from the theme setting.

Multi-Threading support

Complying to the specification [1], DRL AWT can work within multi-threaded applications. This implementation ensures consistency of AWT framework data when accessed by multiple threads. For that, AWT synchronizes its key classes.

Why synchronize

The main purpose of synchronization is keeping the component hierarchy consistent when component properties are queried and/or modified, so that it potentially affects other components. This includes the parent-child relationships, the child component order, inherited properties, such as the font and the background color, the size and position related properties, as well as visibility, focusable state and other conditions relevant for message handling. Concurrent modifications of these properties can make the AWT framework state inconsistent.

For example, if a thread adds a component to a list of child components for a container without updating this component’s field�parent, another thread working with the same component gets the wrong value of the�parent field. Moreover, the second thread may remove this component from the container children list, which makes the behavior of the first thread unpredictable. Synchronization helps avoid such problems.

How to synchronize

When a method or a block of code deals with the data that must not be modified concurrently, a synchronized section is used. The DRL implementation uses a special monitor AWT lock more powerful than built-in Java* synchronized blocks and methods. The AWT lock is similar to the synchronization tools provided by the�java.util.concurrent package. The synchronized section using the AWT lock has its own specifics, as demonstrated by the example below.

Example 2

This example provides an excerpt of code from the�Component class demonstrating a typical synchronized section in the AWT code. The methods�lockAWT() and�unlockAWT() are the boundaries of the critical section. The code between them is synchronized by the AWT lock.

final transient Toolkit toolkit = Toolkit.getDefaultToolkit();
…
public Color getBackground() {
    toolkit.lockAWT();
    try {
        if ((backColor == null) && (parent != null)) {
            return parent.getBackground();
        }
        return backColor;
    } finally {
        toolkit.unlockAWT();
    }
}

From the syntactical standpoint, this is a try-finally structure, which guarantees that the�unlockAWT() method is always called after doing the useful work in the body of try block. Logically, it is used as an ordinary synchronized block, except when using AWT lock extended functionality.

When to synchronize

AWT synchronization covers the following classes:

Components, such as�Component,�Button, and�Frame
Layout managers, such as�FlowLayout and�GridBagLayout
Auxiliary, such as�Toolkit and�KeyboardFocusManager

The total number of synchronized classes nears 40.

Simple data structures, for example,�Rectangle or�Point, are not protected from concurrent modifications for performance reasons.

General rules on how to use synchronized sections

Only public and protected methods of the public API must be synchronized by the AWT lock. Package-private methods and private method are not, with only a few exceptions. For an example, see the�java.awt.Toolkit class.
A synchronized section of code must not call user code, such as event listeners or frequently overridden methods.

Exceptions

Layout managers are always called with the AWT lock.
Certain methods might get overridden by user code, but are called under the AWT lock, for example, the method�addNotify() in the�Component and�Container classes.
Platform-specific code of the�org.apache.harmony.awt.wtk package must not use the AWT lock explicitly.

Note

In platform-specific event handling code, the event listener uses this lock by calling methods�onEventBegin() and�onEventEnd(). These methods call�lockAWT() and�unlockAWT() respectively. This is done to ensure that the dispatcher can find the event target and that the data is not modified by another thread.

Synchronizer

The�org.apache.harmony.awt.wtk.Synchronizer class implements the AWT lock. The�Toolkit class holds the reference to the synchronizer instance. In a standalone application,�Toolkit and�Synchronizer are singleton classes. In the multi-context mode, AWT provides independent�Toolkit and�Synchronizer instances per each context.

Figure 11 shows the inheritance relationship of synchronizer classes. The Linux* and Windows* operating systems have their own classes.

Windows and Linux synchronizers are subclasses of Synchronizer

Figure 11: Synchronizer Classes

The base class�Synchronizer represents a mutex with a high-priority event dispatch thread. All user threads are served in the FIFO (first in first out) order, whereas EDT has higher priority and is served in the LIFO (last in first out) order.

Synchronizer for Linux*

AWT uses the Xlib library to access native window resources on Linux*. The Xlib library is thread-safe and all user and EDT threads can freely access the native system through the AWT interface, as shown in Figure 12. As a result, the class�org.apache.harmony.awt.wtk.linux.LinuxSynchronizer contains no extensions to�java.awt.Synchronizer.

user threads access native resources independently of the EDT thread

Figure 12: Access to the Native System on Linux*

Synchronizer for Windows*

Synchronization on Windows* is different due to Windows* libraries specifics. Firstly, changing the state of a native window usually produces a synchronous event that reports this change. Secondly, only the thread that created a window receives native events related to that window.

In DRL AWT, the event dispatch thread handles all native events and, consequently, is the only thread that can create windows. EDT also changes the window’s state to simplify the native events handling scheme. Non-EDT threads can create and manipulate native windows by giving tasks to EDT. User and EDT threads cooperation is shown in Figure 13.

user threads access native resources via of the EDT thread

Figure 13: Access to the Native System on Windows* with EDT

The�org.apache.harmony.awt.wtk.windows.WinSynchronizer class, the extension of�Synchronizer, implements the interface�NativeServer, which enables user threads to query EDT for access to native resources.

However, delegating access to native resources to EDT requires a more complicated synchronization mechanism. Using the�Synchronizer logic as is results in a potential deadlock while handling native Windows* events. Figure 14 shows the scenario of the deadlock.

thread execution flows with deadlock illustrated

Figure 14: Deadlock with the user thread and EDT

t1: The user thread starts.

t2: EDT starts.

t3: The user thread obtains the AWT lock.

t4: EDT tries to obtain the AWT lock and gets blocked.

t5: The user thread requests a service from EDT via the�NativeServer interface and gets blocked forever because EDT is blocked too.

The�WinSynchronizer class resolves the deadlock issue by combining the synchronizer’s protocol and the native server protocol. For that, EDT switches between handling events and providing access to native resources for other running threads, as shown in Figure 15.

EDT modes

Figure 15. EDT Operation

This algorithm enables detecting a potential deadlock and resolving it. When EDT is requested to provide access to native resources while it is waiting to obtain the AWT lock, EDT awakes, serves the request and resumes waiting. Serving the native resource request is transparent for the event-handling side of EDT because this operation is performed while EDT is inside of�lockAWT() method. The deadlock is resolved, as shown in Figure 16.

Thread execution flow with no deadlock

Figure 16: Deadlock Resolution by WinSynchronizer

t1: The user thread starts.

t2: EDT starts.

t3: The user thread obtains the AWT lock.

t4: EDT tries to obtain the AWT lock and gets blocked.

t5: The user thread requests EDT service and also gets blocked. EDT starts processing the request.

t6: EDT finishes processing request. The user thread resumes.

t7: The user thread releases the AWT lock, EDT obtains it.

t8: The user thread may continue its work or exit.

t9: EDT releases the AWT lock.

t10: EDT continues operation.

References

[1] AWT spec, http://java.sun.com/j2se/1.5.0/docs/guide/awt/index.html

[2] Swing Library Description, http://java.sun.com/j2se/1.5.0/docs/guide/swing/index.html

[3] AWT Focus Subsystem specification, http://java.sun.com/j2se/1.5.0/docs/api/java/awt/doc-files/FocusSpec.html

�

* Other brands and names are the property of their respective owners.