Name: rm29839 Date: 02/23/98


I'm working on some class browsers and other tools
that use the reflection API. They do things like
search the entire classpath for all classes that
implement a particular interface.

The GUI versions of these tools work fine. The
command line versions, however, fail to exit when
done. This is because some of the AWT classes
create one or more threads in their static
initializers, which are invoked when I call
Class.forName(xxx).

This really is only a symptom of a very vexing
problem with the AWT in general. Say that I have
several subprograms running, each of which is
represented by a single Frame. The desired
behavior would be for the program to continue
running as long as one of these frames existed.
However the actual behavior is that the program
fails to exit, since the AWT threads never die.

This is a Bad Thing(tm).

It seems to me, given my assumption that there is
no way to have GUI events coming in without at
last one visible Frame, that when no frames are
visible, the GUI threads should exit. The common
usage is to call System.exit(0) from a window
listener that listens to your 'Main' window, but
this prevents frames from functioning either
as their own main program, or as part of a greater
whole.

There is no way on a user level, without running
a custom class loader that loads a custom version
of Frame, of hooking ALL frame creation and
destruction events, so that's out.

In general, I think this area needs to be
rethought, at least not STARTING a thread until
the first addNotify() is called, and hopefully
terminating it when the last removeNotify() is
called.
(Review ID: 25270)
======================================================================