Menu
I've been integrating the Substance look and feel into my application and ran into several problems regarding it's internal EDT (Event Dispatch Thread) checking routines. Substance absolutely refuses to construct UI classes outside of the EDT. I've done plenty of Swing/AWT and I know most of the rules regarding the EDT. I use SwingWorker, SwingUtilties.invokeLater to modify components. I always though that components could be CONSTRUCTED outside of the EDT, but must be realized and manipulated on the EDT. In other words, you can construct and setup defaults in the background but the call to pack/setVisible must be EDT as well as any subsequent calls to manipulate the component.
The reason I ask is that I have a particularly "beefy" window to construct, involving many widgets, state, and resources (lots of icons). Previously, I constructed the window on the background method of a SwingWorker and made the window visible in the done method. Never had a single problem. Upon switching to Substance, the internal EDT checking bites me.
I've been able to refactor code to get around this. I can construct on the EDT which isn't a good solution since the entire application will block. I can also refactor even more and try my best to load all of the extra resources outside of the EDT.
Wrapping it up ... Is it safe to construct Swing/AWT widgets NOT on the Event Dispatch Thread?
375
Swing event handling code runs on a special thread known as the event dispatch thread. Most code that invokes Swing methods also runs on this thread. This is necessary because most Swing object methods are not "thread safe": invoking them from multiple threads risks thread interference or memory consistency errors.
The event dispatching thread (EDT) is a background thread used in Java to process events from the Abstract Window Toolkit (AWT) graphical user interface event queue.
Since Swing is not thread-safe by design, it's designer did provide couple of utility methods in SwingUtilities class to update any Swing component from a thread other thread Event Dispatcher Thread.
Sun has changed the rules in 2004 -- before, you were allowed to create the components outside the EDT and only had to move into the EDT once the component had been realized.
The new rule now reads:
To avoid the possibility of deadlock, you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread.
this blog post of mine gives more details, including links to other related articles. note that all official Sun examples have been rewritten and are very strict about this.
historically, it probably was the increasing availability of multi-core computers as desktop machines that motivated the re-formulation of the rule -- threading issues became more and more apparent on the client stack, and by being very strict on EDT guidelines, a lot of them can be prevented from the start.
120
No.
Simple reason is that even the EDT likes to deadlock in some rare cases and in general it's easy to deadlock the UI when using Swing (or so I've been told). I suggest you read these three articles from Kirill's (the Substance dev) blog:
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
