This occurs on WinNT351 built as a application.

Run the following in jdb. After the two windows open, close 
them. The JVM doesn't shut down even though there is no 
interesting activity happening. A check of the threads shows the 
following;

threads
Group test1.main:
1. <java.awt.EventDispatcher>... AWT-EventQueue-0   cond. waiting
2. <java.lang.Thread>... AWT-Windows   running
3. <sun.awt.ScreenUpdater>... Scrren Updater   cond. waiting

The AWT-Windows thread should close when there are no 
windows left. Either the dispose isn't sending the cleanup
message properly or AWT-Windows just isn't cleaning up. You 
shouldn't have to use System.exit(0) just because you created 
a window. In complex systems this would be tricky.

import java.awt.*;
import java.awt.event.*;

public class test1 extends Object
{
	public static void main(String args[])
	{
		Frame testframe;

		testframe = new Frame("Test1");
		testframe.addWindowListener(new WindowEventDispatcher(testframe));
		testframe.setVisible(true);

		testframe = new Frame("Test2");
		testframe.addWindowListener(new WindowEventDispatcher(testframe));
		testframe.setVisible(true);
	}
}

class WindowEventDispatcher extends WindowAdapter
{
	Frame thetestframe;

	WindowEventDispatcher (Frame atestframe)
	{
		thetestframe = atestframe;
	}

	public void windowClosing(WindowEvent aWindowEvent)
	{
		System.out.println("WindowClosing event");
		thetestframe.setVisible(false);
//		thetestframe.removeWindowListener(this);
		thetestframe.dispose();
		thetestframe = null;
	}
}


======================================================================

You would have to track the windows you are opening and either
use System.exit(0) or kill the AWT-Windows thread.
======================================================================

================================================================
  xxxxx@xxxxx   (Dec 5, 1997):

Confirmed to be a bug under JDK1.1.2, 1.1.3, 1.1.4, 1.1.5 and 1.2beta2.
Platforms on which tests were done: win32 and sol2.6

Not reproduable under Kestrel 1.3
  xxxxx@xxxxx   2000-09-14

I can reproduce this in 1.3 using Solaris sparc 2.7 and windows NT4.  
However, I cannot reproduce it using merlin beta build 52 with either OS.  
This sounds like a duplicate of 4030718.  
  xxxxx@xxxxx   2001-02-19

In complex systems it is tricky! This bug seems to be
described under Bug ID: 4014091, as well, but there
it is declared a feature used by legacy applications.
I have made up a framework for educational purposes
which consists (apart from other things) of an 
abstraction from the actual IO system used (be it AWT,
console or even a bank terminal) In the entire program 
the reuser does not have to bother whether he uses
AWT or anything else, but when ending the application
he will have to explicitly call System.exit. Although 
this does not appear to be too tricky it is
a) inconvenient and can
b) become tricky if you intend to use several IO
   systems working in parallel inside of one 
   application.

I have been unsuccessful in getting any
work-around to function properly.  Specifically,
Thread.stop(), Thread.interrupt(), and 
Thread.destroy() do not affect the "AWT-Windows"
thread, thus, leaving the trivial application with
at least one additional thread in it's main thread.
Question:  in your "work-around" what do you mean
by "kill the AWT-Windows thread"?  How can any
thread be "kill"ed in Java?

I've seen several variations of this bug described here, and many have been
marked closed with no fix.  I SERIOUSLY hope this bug# will not meet with the
same fate.
Calling System.exit() is unacceptable. It STOPS THE JVM! I should simply be
able to discard all of my objects, stop all of the threads *I* created, and the
JVM should clean up the rest.

This is a real problem when embedding the JVM in a 3rd party application via
the JNI invocation API (e.g. embedding JVM in a web browser as a plugin/ActiveX
control).  If you call System.exit, then the hosting application (browser) will
exit.  If you call the JNI DestroyJavaVM() function, it blocks forever waiting
for the AWT thread to finish.
java.awt.Toolkit should expose an exitEventLoop() method.

In reading other bug evaluations there was supposedly some 
concern about changing this behavior at this late date. If 
that is a concern I would suggest just adding a method 
(probably in the awt toolkit) that basically checked to see 
if it had any current awt components displayed and if not, 
shut down the threads. That way you only get the new, more 
correct behavior if you ask for it.

It is really a shame that this huge bug wasn't fixed yet or a workaround created within the JDK. I couldn't 
manage to stop the awt thread in a test.

Why on earth has this bug been closed as not reproducible? 
The AWT threads do not shutdown when all frames are closed, 
this is a known problem in the AWT design and should 
finally be addressed in Merlin. For now this bug continues 
to exist in all JDK versions up to and including 1.3.0_01 
and is trivially reproducible.

Re-open this bug, or mark it fixed in Merlin!