Java Swing Thread note

A Swing programmer deals with the following kinds of threads:
•Initial threads, the threads that execute initial application code.
•The event dispatch thread, where all event-handling code is executed. Most code that interacts with the Swing framework must also execute on this thread.
•Worker threads, also known as background threads, where time-consuming background tasks are executed.
The programmer does not need to provide code that explicitly creates these threads: they are provided by the runtime or the Swing framework. The programmer's
job is to utilize these threads to create a responsive, maintainable Swing program.

An initial thread schedules the GUI creation task by invoking javax.swing.SwingUtilities.invokeLater or javax.swing.SwingUtilities.invokeAndWait .
Both of these methods take a single argument: the Runnable that defines the new task. Their only difference is indicated by their names:
invokeLater simply schedules the task and returns; invokeAndWait waits for the task to finish before returning.
You can see examples of this throughout the Swing tutorial:
SwingUtilities.invokeLater(new Runnable() {
    public void run() {
        createAndShowGUI();
    }
});

Why does not the initial thread simply create the GUI itself? Because almost all code that creates or interacts with Swing components must
run on the event dispatch thread.

Swing event handling code runs on a special thread known as the event dispatch thread. Most code that invokes Swing methods also runs on
this thread. This is necessary because most Swing object methods are not "thread safe": invoking them from multiple threads risks thread
interference or memory consistency errors. Some Swing component methods are labelled "thread safe" in the API specification;
these can be safely invoked from any thread. All other Swing component methods must be invoked from the event dispatch thread.

It's useful to think of the code running on the event dispatch thread as a series of short tasks.Tasks on the event dispatch thread must finish quickly;
if they don't, unhandled events back up and the user interface becomes unresponsive.

If you need to determine whether your code is running on the event dispatch thread, invoke javax.swing.SwingUtilities.isEventDispatchThread.

SwingWorker provides a number of communication and control features:
•The SwingWorker subclass can define a method, done, which is automatically invoked on the event dispatch thread when the background task is finished.
•SwingWorker implements java.util.concurrent.Future. This interface allows the background task to provide a return value to the other thread. Other methods in this interface allow cancellation of the background task and discovering whether the background task has finished or been cancelled.
•The background task can provide intermediate results by invoking SwingWorker.publish, causing SwingWorker.process to be invoked from the event dispatch thread.
•The background task can define bound properties. Changes to these properties trigger events, causing event-handling methods to be invoked on the event dispatch thread.

When writing a multi-threaded application using Swing, there are two constraints to keep in mind:
Time-consuming tasks should not be run on the Event Dispatch Thread. Otherwise the application becomes unresponsive.
Swing components should be accessed on the Event Dispatch Thread only.

Don't invoke get without arguments unless you are confident that the background task is complete or close to completion.

a single cell renderer is generally used to draw all of the cells that contain the same type of data. When the user starts to edit a cell's data, a cell editor takes over the cell, controlling the cell's editing behavior.
To choose the renderer that displays the cells in a column, a table first determines whether you specified a renderer for that particular column. If you did not, then the table invokes the table model's getColumnClass method, which gets the data type of the column's cells. Next, the table compares the column's data type with a list of data types for which cell renderers are registered. This list is initialized by the table, but you can add to it or change it. Currently, tables put the following types of data in the list:

•Boolean — rendered with a check box.
•Number — rendered by a right-aligned label.
•Double, Float — same as Number, but the object-to-text translation is performed by a NumberFormat instance (using the default number format for the current locale).
•Date — rendered by a label, with the object-to-text translation performed by a DateFormat instance (using a short style for the date and time).
•ImageIcon, Icon — rendered by a centered label.
•Object — rendered by a label that displays the object's string value.
Cell editors are chosen using a similar algorithm.

asks described by Callable can throw checked and unchecked exceptions