Do you want to know the threads all the JVMs or just the one that your
program is in?

And how would you cull them?

Yes.

Arne

There are a variety of mechanisms, of which events and event notification are
a part.  Events are not the same as threads.

There is one thread that rules in Swing: the Event Dispatch Thread (EDT).
All, and that means all, GUI actions (event notifications or otherwise) occur
in this EDT.  Or should, anyway.  All kinds of bugs happen when this is violated.

Conversely, long-running non-GUI actions such as database lookups should not
occur in the EDT, but in the main thread or some subsidiary thread.  Their
visible results get passed into the EDT for (later) viewing by one of the
invokeLater() or SwingWorker mechanisms.  Violation of this paradigm also
causes bugs.

Bear in mind that event notifications, method calls and so forth are not
threads in and of themselves.  They are actions that occur in threads.  The
actions and the threads that execute them are not the same thing.

There are also data items, like instance variables, that are neither actions
nor threads.  They are "resources", things that can be shared between threads.
 These resources need protection both to prevent thread troubles like
deadlock, and to permit communication of results between threads.  The
communication is controlled by the so-called "Java memory model", and the
"synchronized" and "volatile" keywords are very important to managing it.

The important thing for Swing is for GUI actions to occur only on the EDT, and
for non-GUI actions to occur on any other thread but the EDT.