I think there are two levels at which you might try to understand this. The lesser level is to understand what is meant by Swing's rules, and follow them. You could go for a 2nd level in which you try to understand what Swing is doing "under the covers". I am going to attempt an explanation on the first level, there are only parts of the 2nd level I understand anyway.
Sagar Dabas wrote:Today I read this article : Threads and Swings. I got few questions, please help me finding answers.
1 . An applet's GUI can be constructed and shown in the init() method: Existing browsers don't draw an applet until after its init() and start() methods have been called. Thus, constructing the GUI in the applet's init() method is safe, as long as you never call show() or setVisible(true) on the actual applet object.
What is happening in the stroked line ? 
A rule in Swing is that you never call methods to do anything with Swing things except on the event dispatch thread. You can do this by knowing that the routine you are in is only called on that thread (for instance, an action routine called when a button is clicked) or by forcing that code into the thread with Swing's invokeLater or invokeAndWait functions.
[/quote=Sagar Dabas]
The rule applies any time the Swing objects have been "realized", which means that they've had their memory structures filled up, laid out, whatever the heck Swing does when it's going to put things on the screen. And although realization of things is associated with drawing them on the screen, there are cases where they are realized but still aren't on the screen, so you can't equate them exactly.
In the line you underlined, they are saying that this is an exception to that rule. You ARE allowed to do things with Swing in init() and start() on applets, as long as you don't do things to get them realized (like show() and setVisible(), and in fact pack()).
2. Please explain this : The initialization should not occur in the event-dispatching thread; otherwise, repainting and event dispatch would stop.
This is in a section on a "lengthy initialization"; you don't want to do anything that takes a significant amount of elapsed time in the dispatch thread, because that holds up the repainting and other things that take place there. For instance, it is on that thread that your mouse cursor is updated; you don't want that held up while your program accesses a database or reads in a file.
Sagar Dabas wrote:
3. invokeLater(): Requests that some code be executed in the event-dispatching thread. This method returns immediately, without waiting for the code to execute.
What do they mean by return immediately ? What's the use of the code if it is not executed ?
You call invokeLater, your call returns immediately, and the code you handed to invokeLater is called on the dispatch thread. Welcome to multi-threaded programming.
Sagar Dabas wrote:
4. Runnable doWorkRunnable = new Runnable() {
public void run() { doWork(); }
};
Is that any name given to these kind of interface implementation, like anonymous interfaceimplementation 
?
Thanks a lot, you guys are awesome.
The doWork() method is just an example; it is your method, call it what you want. No, it isn't part of an interface or anything.
). All GUI creation and updation should be done in EDT thread.
