A DESCRIPTION OF THE REQUEST :
Instead of making swing components generally thread-safe (as has been requested before and rejected), make just their _models_ thread-safe. I can think of a few different ways to do this, and it would be a much smaller job than trying to make the components generally thread-safe. An example solution: use of the models could be negotiated via ReadWrite locks. Have a supplementary set of models for the swing components that implement an interface, call it Lockable (or somesuch); being aware of this, the swing component will then only read or iterate over (in the case of a ListModel or TableModel, etc) the model when it has obtained a read lock on the model. The user could then obtain Read or Write locks on the model (as the case demanded) and read and modify the model safely from another thread. The only change necessary to the swing component classes is that they be aware if the model is "Lockable", and if it is, obtain a Read lock before reading/iterating. With such an implemention, the current component models would continue to work exactly as they do now, but there would be an easy, transparent solution to the threading mess for people programming more complicated apps. Of course this only one several possible solutions.

JUSTIFICATION :
Currently, programming multithreaded apps with swing is harder and much more cumbersome than it needs to be.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It should be possible to directly alter the data models underlying the swing components from a thread other than the awt event dispatch thread.
ACTUAL -
Currenly is illegal and causes ugly problems.