What is java swing components

Package javax.swing

Provides a set of «lightweight» (all-Java language) components that, to the maximum degree possible, work the same on all platforms. For a programmer’s guide to using these components, see Creating a GUI with JFC/Swing, a trail in The Java Tutorial. For other resources, see Related Documentation.

Swing’s Threading Policy

In general Swing is not thread safe. All Swing components and related classes, unless otherwise documented, must be accessed on the event dispatching thread.

Typical Swing applications do processing in response to an event generated from a user gesture. For example, clicking on a JButton notifies all ActionListeners added to the JButton . As all events generated from a user gesture are dispatched on the event dispatching thread, most developers are not impacted by the restriction.

Where the impact lies, however, is in constructing and showing a Swing application. Calls to an application’s main method, or methods in Applet , are not invoked on the event dispatching thread. As such, care must be taken to transfer control to the event dispatching thread when constructing and showing an application or applet. The preferred way to transfer control and begin working with Swing is to use invokeLater . The invokeLater method schedules a Runnable to be processed on the event dispatching thread. The following two examples work equally well for transferring control and starting up a Swing application:

import javax.swing.SwingUtilities; public class MyApp implements Runnable < public void run() < // Invoked on the event dispatching thread. // Construct and show GUI. >public static void main(String[] args) < SwingUtilities.invokeLater(new MyApp()); >>

import javax.swing.SwingUtilities; public class MyApp < MyApp(String[] args) < // Invoked on the event dispatching thread. // Do any initialization here. >public void show() < // Show the UI. >public static void main(final String[] args) < // Schedule a job for the event-dispatching thread: // creating and showing this application's GUI. SwingUtilities.invokeLater(new Runnable() < public void run() < new MyApp(args).show(); >>); > >

This restriction also applies to models attached to Swing components. For example, if a TableModel is attached to a JTable , the TableModel should only be modified on the event dispatching thread. If you modify the model on a separate thread you run the risk of exceptions and possible display corruption.

Although it is generally safe to make updates to the UI immediately, when executing on the event dispatch thread, there is an exception : if a model listener tries to further change the UI before the UI has been updated to reflect a pending change then the UI may render incorrectly. This can happen if an application installed listener needs to update the UI in response to an event which will cause a change in the model structure. It is important to first allow component installed listeners to process this change, since there is no guarantee of the order in which listeners may be called. The solution is for the application listener to make the change using SwingUtilities.invokeLater(Runnable) so that any changes to UI rendering will be done post processing all the model listeners installed by the component.

As all events are delivered on the event dispatching thread, care must be taken in event processing. In particular, a long running task, such as network io or computational intensive processing, executed on the event dispatching thread blocks the event dispatching thread from dispatching any other events. While the event dispatching thread is blocked the application is completely unresponsive to user input. Refer to SwingWorker for the preferred way to do such processing when working with Swing.

More information on this topic can be found in the Swing tutorial, in particular the section on Concurrency in Swing.

Related Documentation

Источник

Lesson: Using Swing Components

This lesson gives you the background information you need to use the Swing components, and then describes every Swing component. It assumes that you have successfully compiled and run a program that uses Swing components, and that you are familiar with basic Swing concepts. These prerequisites are covered in Getting Started with Swing and Learning Swing with the NetBeans IDE.

Using Top-Level Containers

Discusses how to use the features shared by the JFrame , JDialog , and JApplet classes — content panes, menu bars, and root panes. It also discusses the containment hierarchy, which refers to the tree of components contained by a top-level container.

The JComponent Class

Tells you about the features JComponent provides to its subclasses — which include almost all Swing components — and gives tips on how to take advantage of these features. This section ends with API tables describing the commonly used API defined by JComponent and its superclasses, Container and Component .

Using Text Components

Describes the features and API shared by all components that descend from JTextComponent . You probably do not need to read this section if you are just using text fields (formatted or not) or text areas.

How to.

Sections on how to use each Swing component, in alphabetical order. We do not expect you to read these sections in order. Instead, we recommend reading the relevant «How to» sections once you are ready to start using Swing components in your own programs. For example, if your program needs a frame, a label, a button, and a color chooser, you should read How to Make Frames, How to Use Labels, How to Use Buttons, and How to Use Color Choosers.

Using HTML in Swing Components

Describes how to vary the font, color, or other formatting of text displayed by Swing components by using HTML tags.

Using Models

Tells you about the Swing model architecture. This variation on Model-View-Controller (MVC) means that you can, if you wish, specify how the data and state of a Swing component are stored and retrieved. The benefits are the ability to share data and state between components, and to greatly improve the performance of components such as tables that display large amounts of data.

Using Borders

Borders are very handy for drawing lines, titles, and empty space around the edges of components. (You might have noticed that the examples in this trail use a lot of borders.) This section tells you how to add a border to any JComponent .

Using Icons

Many Swing components can display icons. Usually, icons are implemented as instances of the ImageIcon class.

Solving Common Component Problems

This section discusses solutions to common component-related problems.

If you are interested in using JavaFX to create your GUI, see Using JavaFX Charts and Using JavaFX UI Controls.

Источник

Package javax.swing

Provides a set of «lightweight» (all-Java language) components that, to the maximum degree possible, work the same on all platforms. For a programmer’s guide to using these components, see Creating a GUI with JFC/Swing, a trail in The Java Tutorial. For other resources, see Related Documentation.

Swing’s Threading Policy

In general Swing is not thread safe. All Swing components and related classes, unless otherwise documented, must be accessed on the event dispatching thread.

Typical Swing applications do processing in response to an event generated from a user gesture. For example, clicking on a JButton notifies all ActionListeners added to the JButton . As all events generated from a user gesture are dispatched on the event dispatching thread, most developers are not impacted by the restriction.

Where the impact lies, however, is in constructing and showing a Swing application. Calls to an application’s main method, or methods in Applet , are not invoked on the event dispatching thread. As such, care must be taken to transfer control to the event dispatching thread when constructing and showing an application or applet. The preferred way to transfer control and begin working with Swing is to use invokeLater . The invokeLater method schedules a Runnable to be processed on the event dispatching thread. The following two examples work equally well for transferring control and starting up a Swing application:

import javax.swing.SwingUtilities; public class MyApp implements Runnable < public void run() < // Invoked on the event dispatching thread. // Construct and show GUI. >public static void main(String[] args) < SwingUtilities.invokeLater(new MyApp()); >>

import javax.swing.SwingUtilities; public class MyApp < MyApp(String[] args) < // Invoked on the event dispatching thread. // Do any initialization here. >public void show() < // Show the UI. >public static void main(final String[] args) < // Schedule a job for the event-dispatching thread: // creating and showing this application's GUI. SwingUtilities.invokeLater(new Runnable() < public void run() < new MyApp(args).show(); >>); > >

This restriction also applies to models attached to Swing components. For example, if a TableModel is attached to a JTable , the TableModel should only be modified on the event dispatching thread. If you modify the model on a separate thread you run the risk of exceptions and possible display corruption.

Although it is generally safe to make updates to the UI immediately, when executing on the event dispatch thread, there is an exception : if a model listener tries to further change the UI before the UI has been updated to reflect a pending change then the UI may render incorrectly. This can happen if an application installed listener needs to update the UI in response to an event which will cause a change in the model structure. It is important to first allow component installed listeners to process this change, since there is no guarantee of the order in which listeners may be called. The solution is for the application listener to make the change using SwingUtilities.invokeLater so that any changes to UI rendering will be done post processing all the model listeners installed by the component.

As all events are delivered on the event dispatching thread, care must be taken in event processing. In particular, a long running task, such as network io or computational intensive processing, executed on the event dispatching thread blocks the event dispatching thread from dispatching any other events. While the event dispatching thread is blocked the application is completely unresponsive to user input. Refer to SwingWorker for the preferred way to do such processing when working with Swing.

More information on this topic can be found in the Swing tutorial, in particular the section on Concurrency in Swing.

Related Documentation

The Action interface provides a useful extension to the ActionListener interface in cases where the same functionality may be accessed by several controls.

Источник