title: Safe way to replace AWT EventQueue in running Swing application
body: <p>Various sporadic problems in the Swing application I maintain appear to be caused by the way it replaces the default AWT event queue with its own custom version using <code>Toolkit.getDefaultToolkit().getSystemEventQueue().push(new AEventQueue())</code>. See e.g. <a href="https://stackoverflow.com/questions/9795385/threading-and-deadlock-in-swing-application">Threading and deadlock in Swing application</a>. The problem described there has been resolved, but my tests (using FEST Swing) now tend to run into deadlock.</p>
  
  <p>I suspect the best solution would be to replace the event queue at the beginning of the application initialization, before any Swing components are created. However, there are some dependencies that make that awkward so for the time being I am trying to find a safe way of "pushing" the new event queue after initialization, where it is currently done.</p>
  
  <p>The two approaches I have tried are</p>
  
  <ul>
  <li>push the new queue on the EDT using <code>SwingUtilities.invokeLater()</code>;</li>
  <li>push the new queue on the main thread after initialization, and after using <code>invokeLater()</code> to avoid deadlock with anything already started on the old EDT.</li>
  </ul>
  
  <p>What I would expect, after reading <a href="https://stackoverflow.com/a/8965448/351885">https://stackoverflow.com/a/8965448/351885</a>, is that the first approach might work in Java 7 but something like the second might be needed in Java 1.6. Indeed the second does work in Java 1.6, while in Java 7 both appear to complete successfully but run very very slowly. This may just be a FEST issue since the application itself seems quite responsive.</p>
  
  <p>So I'm pretty much forced to use the second approach, which at least works in Java 1.6, but I would like to know
   - if there is a safer way to implement this, since it seems it might be vulnerable to a race condition if an event appears on the existing queue after <code>invokeLater</code> but before the new queue is created;
   - if there is a different approach I should use instead.</p>
  
  <p><strong>More detail</strong></p>
  
  <p>The first "solution" looks like this:</p>
  
  <pre><code>    initApplication();
      SwingUtilities.invokeLater(new Runnable() {
          @Override
          public void run() {
              Toolkit.getDefaultToolkit().getSystemEventQueue().push(new CustomEventQueue());
          }
      });
  </code></pre>
  
  <p>When compiled and run using Java 1.6, I don't understand what it is doing. It seems the thread is waiting for a lock that it already holds:</p>
  
  <pre><code>"AWT-EventQueue-1" prio=10 tid=0x00007f9808001000 nid=0x6628 in Object.wait() [0x00007f986aa72000]
     java.lang.Thread.State: WAITING (on object monitor)
      at java.lang.Object.wait(Native Method)
      - waiting on &lt;0x00000007d9961cf0&gt; (a atlantis.gui.AEventQueue)
      at java.lang.Object.wait(Object.java:502)
      at java.awt.EventQueue.getNextEvent(EventQueue.java:490)
      - locked &lt;0x00000007d9961cf0&gt; (a atlantis.gui.AEventQueue)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:247)
  </code></pre>
  
  <p>The second "solution" looks like this:</p>
  
  <pre><code>    initApplication();
      try {
          SwingUtilities.invokeAndWait(new Runnable() {
              @Override
              public void run() {
                  logger.debug("Waiting for AWT event queue to be empty.");
              }
          });
      } catch (InterruptedException e) {
          logger.error("Interrupted while waiting for event queue.", e);
      } catch (InvocationTargetException e) {
          logger.error("Error while waiting for event queue.",e);
      }
      Toolkit.getDefaultToolkit().getSystemEventQueue().push(new CustomEventQueue());
  </code></pre>
  
  <p>As stated above, this seems to work OK in Java 1.6 but I'm not convinced it is really safe.</p>
  
  <p>I haven't figured out what is happening when using Java 7, but the main thread seems to spend a long time sleeping the method <code>org.fest.swing.timing.Pause.pause()</code>, which is why I suspect this may be a FEST-specific problem.</p>