Design thread model along with OO model for your Swing application. A thread model defines a scope e.g. a set of classes a thread (or a pool of threads) will stay in. As threads would step out the scope, scopes employ message passing for event notification.

The Problem

The following figure shows the abstraction of a typical Swing application with a back-end. The green arrow represents a connection thread that communicates with a remote server. When there incoming data is received, the connection thread notifies its handlers or listeners e.g. a business model which backs a model for Swing components. Everyone knows what happens next. When a model is changed, it will fire up events to notify Swing components as MVS design pattern suggests.

On the other hand, user may input data from GUI. The event-dispatching thread, represented by the red arrow, invokes Swing component, data model, business model along the path until down to the client that eventually sends out data to the remote server .

Java (or any OOP programming language) invokes method of an object by the calling thread stepping into the called object and executing the code there. Thus no surprise a thread would unexpectedly reach any place in an application through method invocations. It is worse in a Swing application where Observer pattern is widely used.

The Answer

Making every class thread-safe is a wrong answer.

First, it is a mission impossible for a real life project beyond hundreds or thousands line of code. You may want to check out a research paper The Problem with Threads by Professor Edward A. Lee (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html) The paper concludes that multi-threading in non-trivial programs is incomprehensible to humans and can not and should not be trusted.

Second, it is too expensive in terms of money and time. Even if the cost is not an issue, I am wondering whether you can find enough developers who are multi-threading experts on the market to fill up your team.

Third, you may make every class in your application thread-safe but what about Swing classes?

I have addressed this issue by limiting scope for threads, and employing message passing among scopes of thread. 

Thread Model

OO design does not include threads. It may mention thread or concurrency here and there but it does not have a plan of systematically using thread. I suggest you to have a thread model design along with OO design.

I am not able to give thread model a formal definition. A thread model usually contains a set of thread domains which in turn contains: a) A set of classes among which a thread (or a pool of threads) will execute; b) Thread life cycle; c) Subset of classes among which foreign thread may step in; d) Load balancing. There may other important things you want to cover when you put hands on it.

You may view message passing as a upgrade of regular event-driven programming which is common in Swing. When a thread requests to send out an event, the message passing utility will switch to another thread to carry the event to listeners. This way, threads from difference thread models are separated. In the coming posts I will show you source code. They are much simpler than they sound like.

The following figure is the sample above with thread model. All Swing classes with their data models are in the event-dispatching domain. Event-dispatching thread is the only thread here. It means when you write code for Swing classes it is guaranteed no other thread will be running Swing codes. This also protect Swing classes from concurrent accesses. You will find the exact same worry free in the data handling domain and connection domain.

This way, you have three simple single-threading programs to write. If it does not seen valuable to you, imagine a hundred of Swing components in your application.

However I have to mention that it does not prevent you from sharing threads across thread domains.

From the next post, I am going to introduce some source code to demonstrate the design principles here.