+4  A: 

Hi, you can perhaps have a look at this post.

One of the given solution is to execute the SwingWorker instances using your own executor Service. It seems that a change in jdk 1.6 update 18 changed the default behaviour.

Matthieu BROUILLARD
+5  A: 

The problem is, that all Swingworkers run on the same Background-Thread. When you want them to run concurrent you could add them to an Executor Service like this for example:

Executor executor = Executors.newCachedThreadPool();
executor.execute(yourSwingWorker);

Source: Oracle Forums

ymene
@ymene:Yes this solves it.Is there any overhead to this, or it is better to abandon SwingWorker and create my own threads
As far as I know there is nothing wrong with using a threadpool. Its even recommended, since you gain some extra control about when to start threads, how many threads should run at the same time, etc... And concerning SwingWorkers, it just depends on what kind of thread you need. The intent behind SwingWorkers was to keep UI elements updated while having a complex task running in the background and getting information out of this task, while processing or finishing it.
ymene