FULL PRODUCT VERSION :
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b70)
Java HotSpot(TM) Client VM (build 16.0-b07, mixed mode, sharing)
6 Update 18

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7600]

A DESCRIPTION OF THE PROBLEM :
The sample program deadlocks in JDK 7 because there is no new swingworker thread started when issuing the second execute() call. Works with JDK 1.6u16.

It seems that in JDK 7, the SwingWorker pool is not a cached thread pool anymore.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the sample program to observe the deadlock in JDK 7 and its successful run on JDK 6

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application prints "Hello World"
ACTUAL -
Deadlock on sw2.get().

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.SwingUtilities;
import javax.swing.SwingWorker;

public class Swing {
static SwingWorker<String, Void> getWorker2() {
return new SwingWorker<String, Void>() {
@Override
protected String doInBackground() throws Exception {
return "Hello World";
}
};
}
static void runWorker() {
SwingWorker<String, Void> worker = new SwingWorker<String, Void>() {
@Override
protected String doInBackground() throws Exception {
SwingWorker<String, Void> sw2 = getWorker2();
sw2.execute();
return sw2.get();
}
};
worker.execute();
try {
System.out.println(worker.get());
} catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
runWorker();
}
});
}

}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Do not get() on another swing worker from within a doInBackground() or submit the swingworker to a custom cached theadpool instead of execute().

Release Regression From : 6u15
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.