The Source for Java Technology Collaboration
User: Password:
Register | Login help    

Search

Online Books:
java.net on MarkMail:


Thread-Safe Swing Application (Part 1)

Posted by rexyoung on October 6, 2009 at 10:43 PM PDT

Thread-safe is used to describe a Java class that is ready to be accessed by multiple threads without causing deadlock and/or broken state. Here I am referring to how to make an entire application especially a Swing application thread-safe.

It is well known that Swing employs single-thread model. Swing components are desired to be accessed one thread a time. And the event-dispatching thread is preferred. Here is a classic article about multi-threading in Swing (http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html)

In the past months, I have been working on a Swing client application. I call it my application thereafter. My application is an IDE plug-in that needs to use multiple back-end servers. So there are a lot of remote accesses. The requirement on concurrency includes: 

  1. Whenever a lengthy task e.g. accessing remote server or parsing large XML is running, the rest of my application must be available for user to use.

  2. Multiple ongoing tasks are common.

  3. Each ongoing task must display running indicator and progress information to user.

  4. Each ongoing task must allow user to abort the task.

  5. All lengthy tasks should have a configurable timeout parameter to prevent running forever when a user is not around.

Eventually I have completed my application. And as a result, I have worked out some principles, programming techniques, and utilities for developing a thread-safe Swing application. I am going to share them in the coming posts.

 

Related Topics >> Blogs      General      Java Desktop      Programming      Swing      
Comments
Comments are listed in date ascending order (oldest first)

Nice and useful thanks !!

nice !!! another swing interesting post at least !!! I'm tired of glassfish and glassfish and jsf and javascript ones ! thanks it would be so interesting to know how you solve it. And it will help us on Applet / JavaFX / RIA too !!! Great post/s !

Not just preferred...

The AWT event thread is not just preferred; it is the only thread on which it is safe to create or manipulate Swing components, period. The root culprit is the AWT tree lock, which is a global lock. In Swing you, as a matter of course, run foreign code (the look and feel delegate) while in the superclass constructor of any component. That code may easily make some innocent call which acquires the tree lock. Other calls to component methods may or may not acquire the tree lock depending on what the UI delegate implementation does. Try constructing any compound component (adding children will acquire the tree lock) on a background thread while the event thread is holding the tree lock. It is categorically unsafe to construct or call any method on a Swing component (unless that method is explicitly documented to be thread safe and does not trigger any event firing code that might be intercepted by a UI delegate) from any thread but the event thread. For your amusement, here's a query of all historical deadlocks in NetBeans bug database which related to the AWT tree lock: http://bit.ly/moIKv -Tim