JDK-4465537 : AWT Auto shutdown doesn't work when using JScrollPane
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2001-06-04
  • Updated: 2001-07-13
  • Resolved: 2001-07-13
Related Reports
Duplicate :  

Name: boT120536			Date: 06/03/2001

java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

According to the release notes the AWT should no longer prevent the VM from
terminating when the last GUI frame is disposed (though the exact semantics of
this "fix" are not clearly documented). While this seems true for trivial
cases, such as just creating an empty frame, it is not true in only slightly
less trivial cases. In particular the presence of a JScrollPane seems to
prevent the AWT from exiting (perhaps there is a listener somewhere that is
preventing everything from completing??). This simple test program illustrates
the problem:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;

public class ShutdownGUI extends JFrame {

    JScrollPane scrollPane;

    public ShutdownGUI(boolean hang) {
        JList list = new JList();
        if (hang) {
           scrollPane = new JScrollPane(list);
           scrollPane.setPreferredSize(new Dimension(300, 400));
           getContentPane().add(scrollPane, BorderLayout.CENTER);
        else {
           getContentPane().add(list, BorderLayout.CENTER);
        setTitle("Main Frame");
        setSize(300, 400);
    public static void main(String[] args) throws Exception {
        final ShutdownGUI gui = new ShutdownGUI((args.length > 0 ? true :
        gui.addWindowListener( new WindowAdapter() {
                public void windowClosing(WindowEvent evt) {

When run with no arguments, you can close the frame and the application exits
cleanly as expected. When run with an argument, you can close the frame but the
application does not exit. Using ctrl-break to get a full thread dump reveals:

D:\>java ShutdownGUI hang
Full thread dump:

"TimerQueue" daemon prio=5 tid=0x0079E050 nid=0x135 waiting on monitor [909f000.
        at java.lang.Object.wait(Native Method)
        - waiting on <02B8F050> (a javax.swing.TimerQueue)
        at javax.swing.TimerQueue.run(TimerQueue.java:234)
        - locked <02B8F050> (a javax.swing.TimerQueue)
        at java.lang.Thread.run(Thread.java:579)

"Thread-2" prio=5 tid=0x0079ED60 nid=0x126 waiting on monitor [0..6fb30]

"AWT-EventQueue-0" prio=7 tid=0x0079C510 nid=0x17c waiting on monitor [901f000..
        at java.lang.Object.wait(Native Method)
        - waiting on <02EF25C8> (a java.awt.EventQueue)
        at java.lang.Object.wait(Object.java:425)
        at java.awt.EventQueue.getNextEvent(EventQueue.java:325)
        - locked <02EF25C8> (a java.awt.EventQueue)
        at java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:14
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)

        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:131)

        at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)

"AWT-Windows" daemon prio=7 tid=0x00782D40 nid=0x64 runnable [8fdf000..8fdfdc0]
        at sun.awt.windows.WToolkit.eventLoop(Native Method)
        at sun.awt.windows.WToolkit.run(WToolkit.java:215)
        at java.lang.Thread.run(Thread.java:579)

"AWT-Shutdown" prio=5 tid=0x007815A0 nid=0x96 waiting on monitor [8f9f000..8f9fd
        at java.lang.Object.wait(Native Method)
        - waiting on <02ECECC8> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:425)
        at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:262)
        - locked <02ECECC8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:579)

"Signal Dispatcher" daemon prio=10 tid=0x0076A510 nid=0x142 waiting on monitor [

"Finalizer" daemon prio=9 tid=0x00767D00 nid=0x136 waiting on monitor [8c5f000..
        at java.lang.Object.wait(Native Method)
        - waiting on <02E17088> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <02E17088> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:126)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162)

"Reference Handler" daemon prio=10 tid=0x00766960 nid=0x169 waiting on monitor [
        at java.lang.Object.wait(Native Method)
        - waiting on <02E170E8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:425)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110)
        - locked <02E170E8> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=5 tid=0x00765D30 nid=0x174 runnable

"VM Periodic Task Thread" prio=10 tid=0x007698C0 nid=0x97 waiting on monitor
"Suspend Checker Thread" prio=10 tid=0x0076AF00 nid=0x144 runnable
(Review ID: 125704) 

WORK AROUND Name: boT120536 Date: 06/03/2001 Keep using the old "System.exit(0)" hack. ======================================================================

EVALUATION As part of 4417287 we removed the dependancy on an offscreen iamge, as such JScrollBar (in particular MetalBumps) no longer keeps the event dispatching thread around and this test works. Closing this bug as a duplicate of 4417287. scott.violet@eng 2001-07-12