0N/A Copyright (c) 2002, 2006, Oracle and/or its affiliates. All rights reserved. 0N/A DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A This code is free software; you can redistribute it and/or modify it 0N/A under the terms of the GNU General Public License version 2 only, as 0N/A published by the Free Software Foundation. Oracle designates this 0N/A particular file as subject to the "Classpath" exception as provided 0N/A by Oracle in the LICENSE file that accompanied this code. 0N/A This code is distributed in the hope that it will be useful, but WITHOUT 0N/A ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A version 2 for more details (a copy is included in the LICENSE file that 0N/A accompanied this code). 0N/A You should have received a copy of the GNU General Public License version 0N/A 2 along with this work; if not, write to the Free Software Foundation, 0N/A Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 0N/A Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A<
h1 align=center>AWT Threading Issues</
h1>
0N/A<
a name="ListenersThreads"></
a>
0N/A<
h2>Listeners and threads</
h2>
0N/AUnless otherwise noted all AWT listeners are notified on the event
0N/Adispatch thread. It is safe to
remove/
add listeners from any thread
0N/Aduring dispatching, but the changes only effect subsequent notification.
0N/A<
br>For example, if a key listeners is added from another key listener, the
0N/Anewly added listener is only notified on subsequent key events.
0N/A<
a name="Autoshutdown"></
a>
0N/A<
h2>Auto-shutdown</
h2>
0N/AJava</
i><
sup><
small>TM</
small></
sup> <
i>Virtual Machine Specification,
0N/Athe Java virtual machine (JVM) initially starts up with a single non-daemon
0N/Athread, which typically calls the <
code>main</
code> method of some class.
0N/AThe virtual machine terminates all its activity and exits when
0N/Aone of two things happens:
0N/A <
li> All the threads that are not daemon threads terminate.
0N/A <
li> Some thread invokes the <
code>exit</
code> method of class
0N/A <
code>Runtime</
code> or class <
code>System</
code>, and the exit
0N/A operation is permitted by the security manager.
0N/AThis implies that if an application doesn't start any threads itself,
0N/Athe JVM will exit as soon as <
code>main</
code> terminates.
0N/AThis is not the case, however, for a simple application
0N/A public static void main(String[] args) {
0N/A Frame frame = new Frame();
0N/AThe reason is that AWT encapsulates asynchronous event dispatch
0N/Amachinery to process events AWT or Swing components can fire. The
0N/Aexact behavior of this machinery is implementation-dependent. In
0N/Aparticular, it can start non-daemon helper threads for its internal
0N/Apurposes. In fact, these are the threads that prevent the example
0N/Aabove from exiting. The only restrictions imposed on the behavior of
0N/Athis machinery are as follows:
0N/A returns <
code>true</
code> if and only if the calling thread is the
0N/A event dispatch thread started by the machinery;
0N/A <
li> <
code>AWTEvents</
code> which were actually enqueued to a
0N/A particular <
code>EventQueue</
code> (note that events being
posted to the <
code>EventQueue</
code> can be coalesced) are
<
dd> That is, it is not permitted that several events from
this queue are dispatched simultaneously.
<
li> In the same order as they are enqueued.
<
dd> That is, if <
code>AWTEvent</
code> A is enqueued
to the <
code>EventQueue</
code> before
<
code>AWTEvent</
code> B then event B will not be
dispatched before event A.
<
li> There is at least one alive non-daemon thread while there is at
least one displayable AWT or Swing component within the
The implications of the third restriction are as follows:
<
li> The JVM will exit if some thread invokes the <
code>exit</
code>
method of class <
code>Runtime</
code> or class <
code>System</
code>
regardless of the presence of displayable components;
<
li> Even if the application terminates all non-daemon threads it
started, the JVM will not exit while there is at least one
It depends on the implementation if and when the non-daemon helper
threads are terminated once all components are made undisplayable.
The implementation-specific details are given below.
Implementation-dependent behavior.
Prior to 1.4, the helper threads were never terminated.
Starting with 1.4, the behavior has changed as a result of the fix for
4030718</
a>. With the current implementation, AWT terminates all its
helper threads allowing the application to exit cleanly when the
following three conditions are true:
<
li> There are no displayable AWT or Swing components.
<
li> There are no native events in the native event queue.
<
li> There are no AWT events in java EventQueues.
Therefore, a stand-alone AWT application that wishes to exit
<
li> Make sure that all AWT or Swing components are made
undisplayable when the application finishes. This can be done
on all top-level <
code>Windows</
code>. See
<
li> Make sure that no method of AWT event listeners registered by
the application with any AWT or Swing component can run into an
infinite loop or hang indefinitely. For example, an AWT listener
method triggered by some AWT event can post a new AWT event of
the same type to the <
code>EventQueue</
code>.
The argument is that methods
of AWT event listeners are typically executed on helper
Note, that while an application following these recommendations will
exit cleanly under normal conditions, it is not guaranteed that it
will exit cleanly in all cases. Two examples:
<
li> Other packages can create displayable components for internal
needs and never make them undisplayable. See
<
li> Both Microsoft Windows and X11 allow an application to send native
events to windows that belong to another application. With this
feature it is possible to write a malicious program that will
continuously send events to all available windows preventing
any AWT application from exiting cleanly.
On the other hand, if you require the JVM to continue running even after
the application has made all components undisplayable you should start a
non-daemon thread that blocks forever.
Runnable r = new Runnable() {
} catch (InterruptedException ie) {
Thread t = new Thread(r);
The Java Virtual Machine Specification guarantees
that the JVM doesn't exit until this thread terminates.