Jeff, the article states:
"The class NoThreadsSample has only one thread of execution and you won''t be able to type anything in the text field until the loop is done. This loop exclusively takes all processor''s time, that''s why the window is locked"

What happens if I have a 2 CPU box ? One CPU will be 100%, but the other will be 0%, plenty of resource to type in the text field.
The fact that you cannot type in the text field is absolutely not related to the fact that the "loop exclusively takes all processor''s time", but more to Swing''s architecture.
For further info, read the links I gave. They will explain the Swing "freeze" problem (the author refer to it as "the window is locked"), and the Swing architecture as well.

Simon, you stated:

"First of all, the single thread rule of Swing is violated (setTitle() is called from outside the event dispatch thread). This is a gross mistake, especially when there is no explanation on why it has been done. Second, it is said that the reason why it is not possible to type in the textfield is that because the CPU is 100% busy. This is clearly false, and shows bad understanding of how Swing works."

Can you please explain your answers here? I''m a noob so saying something is "clearly false" without a "why" doesn''t help me. Thanks!

Read again - carefully this time - the article you mention, and you''ll see that your example *does* violate the single thread rule.

Also, I suggest you to read the second and third continuations of the same article.
For interested readers, since those resources are not mentioned by your article, here are the links:
http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html
http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html
http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html

Another good reference for Swing threading is this:
http://foxtrot.sourceforge.net/
especially here:
http://foxtrot.sourceforge.net/docs/toc.php

About the catch 22 situation, I would say you shoot in your foot, since 99% of thread tutorials out there do not use Swing as a first thread example, exactly because it requires too much background. Noone forced you to use a wrong example, to talk about wrong problems (the 100% CPU thing) and to suggest wrong solutions for them.

Once more, not good.

It''s just unfortunate that only few readers, after reading the article, take the time to read the comments.

1. Calling setTitle() from the actionPerformed is fine and does not violate Swing''s single thread rule because actionPerformed() method is automatically invoked in the dispath-thread (see http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html)

2. I agree that calling another thread from the actionPerformed() should have been done using invokeLater(), but it''s a catch 22 situation: I can''t explain this without explaining thread basics first. Probably I should have mention that Swing has its special way of working with threads.
But again, I just try to explain one Java feature at a time...

Hi,
while I understand this is a simple example and an introductory article on threads, I am surprised by the errors it contains.
First of all, the single thread rule of Swing is violated (setTitle() is called from outside the event dispatch thread). This is a gross mistake, especially when there is no explanation on why it has been done.
Second, it is said that the reason why it is not possible to type in the textfield is that because the CPU is 100% busy. This is clearly false, and shows bad understanding of how Swing works. Furthermore, it is proposed as a solution to move the code in another thread, which is even worse (see previous point).
Third, it is possible to start more than one worker but the example does not seem to handle this situation.
Fourth, as already noted by Marc, catching an InterruptedException without re-interrupting the current thread is bad practice.

I think stating right things from the beginning, especially if the goal of the article is to be an introduction to threads for people that don''t know them, is a better approach.
Correcting things lately will always be too late, and when people will violate Swing''s single thread rule as a normal coding style, they will always have the justification that they read an article that did so. Not good.

Marc,

This is a just a first light intro to threads and my sample code is written properly. At the end of the article I''ve also mentioned that you may need to close all io resources when killing a thread.

Your suggestion with interrupt() may not always work with threads that have opened streams. It''s recommended to stop such threads by simple closing these streams, connections, etc.

Let''s keep things simple for now :)

If your while loop launches more threads, or does blocking IO operations, the main thread (with the invariant while (!stopThreadFlag)) will end but you still have open resouces and other threads that may still be running.

A better (albeit not as elegant) mechanism to use would be the interrupt() method.

Here is a rewritten version using it. I''m sure this comment box will screw up formatting.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class ThreadStopSample extends JFrame implements ActionListener, Runnable {

Thread worker = null;

// Constructor
ThreadStopSample() {
// Create a frame with a button and a text field
GridLayout gl = new GridLayout(2, 1);
this.getContentPane().setLayout(gl);
JButton myButton = new JButton("Start/Stop Thread");
myButton.addActionListener(this);
this.getContentPane().add(myButton);
this.getContentPane().add(new JTextField());
}

public void actionPerformed(ActionEvent e) {
if (worker != null && worker.isAlive()) {
worker.interrupt();
} else {
worker = new Thread(this);
worker.start();
}
}

public void run() {
int i = 0;
while (true) {
try {
this.setTitle("i=" + i);
i++;
Thread.sleep(1);
} catch (InterruptedException ie) {
Thread.currentThread().interrupt();
break;
}
}
}

public static void main(String[] args) {
ThreadStopSample myWindow = new ThreadStopSample();
myWindow.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
myWindow.setBounds(0, 0, 150, 100);
myWindow.setVisible(true);
}

}