A DESCRIPTION OF THE FIX :
I believe the ThreadPool creation code in SwingWorker is dubious and should be replaced by standard java.util.concurrent functionality. According to the comment in SwingWorker.java, the thread pool is intended to have no more than MAX_WORKERS threads which time out after one second and an unbounded job queue. Instead of working around the distinction between core and normal worker threads as SwingWorker does today, it is possible to have core threads time out, too, using the allowCoreThreadTimeout method.
Posted Date : 2006-10-10 16:54:58.0

N/A

Contribution forum : https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=16028
Posted Date : 2006-10-10 16:59:20.0

We needed to have threads time out so  SwingWorker's executor service does not prevent VM from exiting while there are no submitted tasks. 

The better way to do this is to make worker threads daemon threads and to shutdown SwingWorker executor service on application shutdown using Runtime.addShutdownHook so all submitted tasks are executed.
Posted Date : 2007-08-03 20:15:31.0

There is a sub-issue mentioned here -- SwingWorker does not use daemon threads, and thus sometimes lets the process stay open longer than it really needs to.  I have had one situation where I dispose()d the final window in the GUI, and the application stayed up even though the only thread running was a SwingWorker threadpool one.

Using the shutdown hook wouldn't make sense because those only run once the JVM actually starts shutting down -- if there is a non-daemon thread hanging around then it won't even get to that point.