The answer here has to do with Java's thread scheduling implementation (or rather, the specifics of your platform's Java thread scheduling implementation). Most Java threading implementations wind up running a given thread (at a given priority level) until the thread enters a wait condition. Then the next thread in that priority level runs, etc... Note that the JVM spec does not specify the exact behavior - that's up to the JVM implementer to decide.
Instead of inserting sleeps into your worker thread, you may want to consider dropping the priority of the worker. Sleeping the thread will work, but it's a hassle to remember to do it, and it forces the worker thread to take longer to do things than it would otherwise have to. If you do wind up inserting sleep calls, do it for 0 milliseconds (that's enough to release the thread, but should return to executing immediately if there are no other threads active).
Here's an article that describes this a bit.
As a potential refinement: The invokeLater() call may wind up placing the runnable in a queue that never has a chance to dequeue because your background thread is taking all the CPU. An interesting experiment would be to move the startup of your background thread int the Runnable - this would give the EDT a chance to initialize before your background thread starts consuming the CPU.
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI(); // <-- creates the swing frame and component
Thread t = new Thread(new InfiniteLoop());
t.start();
}
});
}
or even:
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
Thread t = new Thread(new InfiniteLoop());
t.start();
createAndShowGUI(); // <-- creates the swing frame and component
}
});
}
I'd actually be interested in the results of this (not interested enough to actually test it, though :-) ). Some references I see online say that the EDT runs at a higher priority level by default (in which case, the EDT itself shouldn't be experiencing starvation). If you start the background thread from inside the EDT, does the Swing interface remain responsive?