Hopefully one of the more seasoned Swing coders can correct me if I get this wrong (it's been a looong while since I've done any Swing work), but from my recollection Swing has very specific rules about things that must be one the main event Thread and things that should be run off of it.
My guess is that Swing does not like that you are creating GUI objects from three different Threads. This has nothing to do with multiple Threads instantiating the same class. The problem is that they're doing Swing operations.
The quick fix that should
solve the problem (as opposed to mitigate it as you have done, i.e. solve it "most of the time" but not guarantee success) is to instantiate the GUI objects in your main thread and pass their references to your Threads.
Using this
pattern, only one Thread is doing all the Swing stuff, avoiding the intermittent problem you were seeing and could see if you run on hardware with different performance characteristics.
As you go forward, you may find that having the three Threads operate on their GUI TextDisplays causes other strange behavior, but at this point I will be totally guessing. Any Swing guru care to elaborate?
A couple notes about this as some free advice. Unless you're alternig the behavior of the Thread itself, it's best to make your tasks (FileGetter and FileProcessor) implement Runnable -- override run() method -- instead of extend Thread. This allows a more flexible design as you go forward, better reuse, and the possibility of using with a thread pool or other architecture.
Also, you probably pass the two FGs into the FP, so you'll want to instantiate the FGs outside of the Threads, store the references, and pass them to the new Thread() calls and the new FP() call. You're doing some complex stuff here, so I've assumed you can handle that part on your own.
If you have any questinos or need clarification, let's hear it.
[ February 17, 2005: Message edited by: David Harkness ]