Thread-safe selection and swing in Java development

The Swing API is designed to be powerful, flexible, and easy to use. In particular, we want to make it easy for programmers to create new swing components, either from scratch or by extending some of the components we provide.

For this purpose, we do not require swing components to support multithreaded access. Instead, we send the request to the component and execute the request on a single thread.

This article discusses threads and swing components. The goal is not only to help you use the swing API in a thread-safe way, but also to explain why we chose the threading scheme now.

This article includes the following:

Single-threaded rule: Swing threads can only be accessed by one thread at a time. Typically, this thread is an event-distributing thread (event-dispatching thread).
Exceptions to the rule: some operations are guaranteed to be thread-safe.

Event Distribution: If you need to access the UI outside of event handling (event-handling) or drawing code, you can use the Invokelater () or invokeandwait () method of the Swingutilities class.

To create a thread: If you need to create a thread--for example, to work with a lot of computational power or I/O limitations--You can use a threading tool class such as SwingWorker or a timer.

Why we implement swing this way: We'll end this article with some background information about swing's thread safety.

The rules of Swing are:

Once the swing component is materialized (realized), all code that may affect or depend on the component state should be executed in the event-issuing thread.

This rule may sound a bit scary, but for many simple programs, you don't have to worry about threading problems. Before we go into how to write swing code, let's define two terms: materialized (realized) and event-Distributing threads (event-dispatching thread).

Materialized means that the paint () method of the build has been or may be invoked. A swing component that acts as a top-level window will be materialized when the following methods are invoked: SetVisible (True), show (), or (perhaps surprise you) pack (). When a window is materialized, it contains all the components that are present. Another way to present a component is to put it into a container that is already in the process of being materialized. You'll see some examples of how the components are being materialized later.

The event-issuing thread is the thread that executes the drawing and event handling. For example, the paint () and actionperformed () methods are automatically executed in the event-distributing thread. Another way to put code into an event-distributing thread is to use the Invokelater () method of the Swingutilities class.

All code that might affect an already existing swing component must be executed in the event-issuing thread. But there are some exceptions to this rule:

Some methods are thread-safe: In the documentation for the Swing API, thread-safe methods are marked with the following text:

This is thread safe, although most Swing methods are.
(This method is thread-safe, although most swing methods are not.) ）

The GUI for an application can often be built and displayed in the main thread: The following typical code is safe, as long as no components (swing or other) are materialized:

public class MyApplication
{
public static void Main (string[] args)
{
JFrame f = new JFrame ("Labels"); Here will be the components
Add to Main frame ...
F.pack ();
F.show ();
Do not do any GUI work ...
}
}