I've got a thread dump of an applet running on JVM 1.6.0_12 in Opera 9.64 Build 10487 - and it shows three event queues! As far as I know the Java Swing event handling is single threaded - did this change in any recent update?
My problem is, that multiple event queues will tend to cause deadlocks since I've got some more locks than only the GUI TreeLock.
There can be more than one, and it depends on the browser. EventQueue documentation says:
Some browsers partition applets in different code bases into separate contexts, and establish walls between these contexts. In such a scenario, there will be one EventQueue per context. Other browsers place all applets into the same context, implying that there will be only a single, global EventQueue for all applets. This behavior is implementation-dependent.
Yes. Typically there will be only one Toolkit for Toolkit.getDefaultToolkit, but multiple EventQueues from Toolkit.getSystemEventQueue (which from 1.2.2 you typically get permissions to call successfully). There is magic based on ThreadGroup and ClassLoaders on the stack to determine which EventQueue to return.
Applets are partitioned dependent upon their origin and configuration. Exactly how this is done is implementation dependent.
Now, what you are probably seeing is an event queue for your applet and the secure context. The secure context handles the dialog boxes from the plugin itself. Accepting certificates and things like that. The secure context keeps these away from user code in your applet context.
In addition, Swing creates a new EventQueue (and thread IIRC) when you show a modal dialog, this event queue is active (the previous one is "on hold") until the modal dialog is closed.
However, I'm not sure what happens when having several levels of modal dialogs (1 main queue + 1 queue per dialog, or 1 main queue + 1 queue for all dialogs).
"Swing creates a new EventQueue (and thread IIRC) when you show a modal dialog" Actually it is wrong. I discussed this some time ago with Swing guy and Swing only adds new filter on existing event queue to filter out events comming from different source (window/component). So no new thread/EQ is created for modal dialog. You can verify this by opening modal dialog and getting thread dump before and after modal dialog is opened and compare AWT thread call stack. At least it is how it is with standard Java app. I did not check applet case yet.