Welcome to the wonderful world of blocked Event Dispatching Thread (and violation of the initial thread)
Basically, Swing is a single threaded environment, all updates and modifications to the UI are expected to be executed within the context of the Event Dispatching Thread (AKA EDT).
The EDT is responsible for, amongst other things, processing repaint requests. If, for some reason, you block this thread (for example, using a long running loop or blocking IO), it will prevent the EDT from processing new paint requests, making it appear as if your program has hung...because essentially it has.
The reason you might see a difference between running Timer
directly and using it in your GUI is because when the application is started, it will be running within, what is commonly known as, the "main" thread.
When you first create a top level Swing container, the EDT is started (which is a separate thread), meaning that the UI will appear in it's own thread, but the application will continue running in the "main" thread, allowing your iterate
method to run independently of the EDT.
However, when you try and run it from within your GUI, it's all running within the context of the EDT, causing it to be blocked.
Start by taking a look at
To fix the problem, based on your example code, I would suggest using a SwingWorker
. This will allow you to run your "long running task" in a background thread, but provides a number of methods that allow you to resync your updates back to the EDT. This is very important, as you should never attempt to update the UI or change it's state from any thread other then the EDT.
Take a look at Worker Threads and SwingWorker for more details
And if required, some examples...