JDK-6480289 : Replace ThreadPool creation code in SwingWorker with java.util.concurrent
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-10-10
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b22Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
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.

Comments
EVALUATION 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.
03-08-2007

EVALUATION Contribution forum : https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=16028
10-10-2006