JDK-2190543 : SwingWorker deadlocks due one thread in the swingworker-pool
  • Type: Backport
  • Backport of: JDK-6880336
  • Component: client-libs
  • Sub-Component: javax.swing
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2010-03-22
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
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 6 JDK 7
6u21Fixed 7 b94Fixed
Comments
EVALUATION Although the described behavior with the deadlock doesn't contradict SwingWorker specification: An abstract class to perform lengthy GUI-interacting tasks in a dedicated thread. we still want to fix this problem. Currently, the fix is to increase the core pool size for ThreadPoolExecutor underneath SwingWorker implementation, but one should still realize that it's possible to write a test with MAX_INT SwingWorkers nested into each other that would still deadlock. That's why the fix should also include a JavaDoc warning about the threading strategy used: developers shoult not rely on any particular one.
14-04-2010