<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>

<HEAD>
<!--
Copyright (c) 1998, 2006, Oracle and/or its affiliates. All rights reserved.
DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

This code is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License version 2 only, as
published by the Free Software Foundation.  Oracle designates this
particular file as subject to the "Classpath" exception as provided
by Oracle in the LICENSE file that accompanied this code.

This code is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
version 2 for more details (a copy is included in the LICENSE file that
accompanied this code).

You should have received a copy of the GNU General Public License version
2 along with this work; if not, write to the Free Software Foundation,
Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
CA 95054 USA or visit www.sun.com if you need additional information or
have any questions.
-->

        <META NAME="Author" Content="Eric Armstrong">
        <META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
        <TITLE>swing package</TITLE>
</HEAD>

<BODY bgcolor="white">

<P>Provides a set of &quot;lightweight&quot;
(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
<a href="http://java.sun.com/docs/books/tutorial/uiswing/index.html" 
target="_top">Creating
a GUI with JFC/Swing</a>, a trail in <em>The Java Tutorial</em>.
For other resources, see 
<a href="#related">Related Documentation</a>.

<H2><a name="threading">Swing's Threading Policy</a></h2>

In general Swing is not thread safe. All Swing components and related
classes, unless otherwise documented, must be accessed on the event
dispatching thread.
<p>
Typical Swing applications do processing in response to an event
generated from a user gesture. For example, clicking on a {@code
JButton} notifies all {@code ActionListeners} added to the {@code
JButton}. As all events generated from a user gesture are
dispatched on the event dispatching thread, most developers are not
impacted by the restriction.
<p>
Where the impact lies, however, is in constructing and showing a
Swing application. Calls to an application's {@code main} method,
or methods in {@code 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 {@code invokeLater}. The {@code
invokeLater} method schedules a {@code 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:
<pre>
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(args));
    }
}
</pre>
Or:
<pre>
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();
            }
        });
    }
}
</pre>
This restriction also applies to models attached to Swing components.
For example, if a {@code TableModel} is attached to a {@code
JTable}, the {@code 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.
<p>
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 {@link javax.swing.SwingWorker} for the preferred way to do such
processing when working with Swing.
<p>
More information on this topic can be found in the
<a href="http://java.sun.com/docs/books/tutorial/uiswing/">Swing tutorial</a>,
in particular the section on
<a href="http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html">How to Use Threads</a>.


<H2>
<a name="related">Related Documentation</a>
</H2>
<P>For overviews, tutorials, examples, guides, and other documentation, please see:

<UL>
   <LI><A HREF="http://java.sun.com/products/jfc/tsc/" 
   target="_top">The Swing Connection</A>
   <LI><A HREF="http://java.sun.com/docs/books/tutorial/" 
   target="_top">The Java Tutorial</A>
   <LI><A HREF="http://developer.java.sun.com/developer/onlineTraining/" 
   target="_top">Online Training</A> at the Java Developer Connection<font size=-2><sup>SM</sup></font>
   <LI><A HREF="http://java.sun.com/products/jfc/" 
   target="_top">Java Foundation Classes (JFC)</A> home page
</UL>

@serial exclude

</BODY>
</HTML>