What starts the event dispatch thread?

[Simon]

Hi,

I have a rather largish application that uses lots of libraries and
comes in a command line version, a GUI version, and parts of it are used
in an enterprise application. Something in it seems to be starting the
EventDispatchThread, also in the non GUI versions.

Some components are craeating GUI elements or instances from the
java.awt package (Icons, Images, etc) which might relate to that. E.g.,
on Windows, creating a JPanel but displaying nothing starts two Threads
named "AWT-Windows" and "AWT-Shutdown" (not "AWT-EventQueue-0"!).

- Where can I find documentation on which events cause the
EventDispatchThread to be started?

- Is there a tool or maybe a debugging technique to hook into the method
that starts the event queue so I can inspect stack frames to spot the
method call which eventually results in starting the thread.

- Creating and displaying GUI elements is forbidden in enterprise
applications. Is it allowed to create a JPanel and use its paint()
method to draw on a BufferedImage which I then send to a Web client as a
PNG. Or is it already forbidden to do anything that starts an "AWT-*"
thread?

Cheers,
Simon

 

[John B. Matthews]

I have a rather largish application that uses lots of libraries and
comes in a command line version, a GUI version, and parts of it are
used in an enterprise application. Something in it seems to be
starting the EventDispatchThread, also in the non GUI versions.

Some components are craeating GUI elements or instances from the
java.awt package (Icons, Images, etc) which might relate to that.
E.g., on Windows, creating a JPanel but displaying nothing starts two
Threads named "AWT-Windows" and "AWT-Shutdown" (not
"AWT-EventQueue-0"!).

- Where can I find documentation on which events cause the
EventDispatchThread to be started?

- Is there a tool or maybe a debugging technique to hook into the
method that starts the event queue so I can inspect stack frames to
spot the method call which eventually results in starting the thread.

- Creating and displaying GUI elements is forbidden in enterprise
applications. Is it allowed to create a JPanel and use its paint()
method to draw on a BufferedImage which I then send to a Web client
as a PNG. Or is it already forbidden to do anything that starts an
"AWT-*" thread?

It doesn't address your question directly, but you might set
-Djava.awt.headless=true and see who throws java.awt.HeadlessException:

<http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless>

 

[Simon]

It doesn't address your question directly, but you might set

-Djava.awt.headless=true and see who throws java.awt.HeadlessException:

<http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless>

That's a very good idea. I have made some tests, and, unfortunately
my application never throws one in command line mode. In fact, a
HeadlessException is thrown whenever I make a frame visible. However,
merely triggering any of the mentioned AWT threads does not suffice.

Cheers,
Simon

 

[Lew]

- Where can I find documentation on which events cause the
EventDispatchThread to be started?

The reason is that AWT encapsulates asynchronous event dispatch machinery to
process events AWT or Swing components can fire. The exact behavior of this
machinery is implementation-dependent. In particular, it can start non-daemon
helper threads for its internal purposes.

From this I glean that it's not mandated exactly when the EDT starts, though
I've always inferred that it starts with the first AWT action (e.g., creation
of a Component).

 

[John B. Matthews]

It doesn't address your question directly, but you might set
-Djava.awt.headless=true and see who throws java.awt.HeadlessException:

<http://java.sun.com/j2se/1.4.2/docs/guide/awt/

AWTChanges.html#headless>

That's a very good idea. I have made some tests, and, unfortunately
my application never throws one in command line mode.[/QUOTE]

That's precisely how I use it to maintain a combined GUI/CL project. I
can set headless in the CL script, which also helps me keep GUI elements
from creeping into the CL.

In fact, a HeadlessException is thrown whenever I make a frame
visible. However, merely triggering any of the mentioned AWT threads
does not suffice.

This example uses reflection to give main() control over loading the GUI
libraries:

<http://applecommander.cvs.sourceforge.net/viewvc/applecommander/
AppleCommander/src/com/webcodepro/applecommander/ui/AppleCommander.java>

 

[John B. Matthews]

- Where can I find documentation on which events cause the
EventDispatchThread to be started?
<http://java.sun.com/javase/6/docs/api/java/awt/doc-files/

AWTThreadIssues.html#Autoshutdown>

"The exact behavior of this machinery is implementation-dependent."

[/QUOTE]

Interesting. On my platform the following program causes the OS to
establish a GUI application, altering several desktop widgets
accordingly. Running with -Djava.awt.headless=true precludes this, and
the profiler shows the (empty) EDT waiting until the JVM terminates:

import java.awt.EventQueue;
public class QTest {
public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
public void run() {
}
});
}
}

From this I glean that it's not mandated exactly when the EDT starts,
though I've always inferred that it starts with the first AWT action
(e.g., creation of a Component).

Or even an (essentially) empty EventQueue.

 

[Roedy Green]

- Where can I find documentation on which events cause the
EventDispatchThread to be started?

I would hazard a guess that the post an event method would check if
there is a thread to service the events, and if not start it.

You might find the relevant code by tracing what happens when you
create a synthetic event.

See http://mindprod.com/jgloss/event11.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Let us pray it is not so, or if it is, that it will not become widely known."
~ Wife of the Bishop of Exeter on hearing of Darwin's theory of the common descent of humans and apes.

 

[neuneudr]

- Where can I find documentation on which events cause the
EventDispatchThread to be started?

And to be *re*started. It's not 'the' EDT as if there was
one unique EDT troughout the app's lifetime. The EDT dying
and another EDT being restarted is actually quite common
(and can be trivially tested/reproduced). Bugs in official APIs,
bugs in third-party APIs, bugs in your app, bugs in some JVM can
all kill the EDT. A new EDT is then immediately restarted.

Some broken application break because their author were unaware
of this and thought there was one unique, never changing, EDT
and did 'smart' thing such as joining on that supposedly unique EDT

 

[Daniel Pitts]

And to be *re*started. It's not 'the' EDT as if there was
one unique EDT troughout the app's lifetime. The EDT dying
and another EDT being restarted is actually quite common
(and can be trivially tested/reproduced). Bugs in official APIs,
bugs in third-party APIs, bugs in your app, bugs in some JVM can
all kill the EDT. A new EDT is then immediately restarted.

Some broken application break because their author were unaware
of this and thought there was one unique, never changing, EDT
and did 'smart' thing such as joining on that supposedly unique EDT

Not to mention modal dialog boxes will create a new EDT and push the
blocked one onto a stack.

 

[kvforum]

In article <[email protected]>, Lew <[email protected]>
wrote:

Interesting. On my platform the following program causes the OS to
establish a GUI application, altering several desktop widgets
accordingly. Running with -Djava.awt.headless=true precludes this, and
the profiler shows the (empty) EDT waiting until the JVM terminates:

import java.awt.EventQueue;
public class QTest {
public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() {
public void run() {
}
});
}
}


I'm was having trouble getting the EDT to start in the command line app I'm editing. The person is using a javax.swing.Timer when I wish they were using something else (like an ExecutorService).

Anyway, no matter what I did, the timer would not fire. Turns out the EDT was not running even in a stripped-down test program. To start the thread, I tried your code above and it works. I simplified it and was able to start the thread with any call to the EventQueue including:

EventQueue.isDispatchThread();

Which is what I'm using as a workaround to start the EDT in the application. Hope that helps someone else, too.

-gMale