One big problem in Swing applications is the execution of long running operations. The Swing Application Framework has a small solution with their Task and TaskService. But the problem remains when also Runnable objects should be executed and the user interface be blocked.
I looked at the common way of executing Runnable objects in Java 6 and found Executor and its child interfaces and implementing classes in java.util.concurrent. So this seems to be a good starting point for a solution.
I extended the ExecutorService interface and provided notifications about adding, removing a command and also about the execution or rejection of a command. This interface is implemented by an extension of ThreadPoolExecutor called SwingThreadPoolExecutor which manages the blocking of user input during execution.
Doing it this way allows me to also block the user interface for a Runnable or SwingWorker. Also the blocking dialog can show a list of all currently executing commands like the progress dialog of Eclipse and the user can cancel commands if required. Another problem is often that there can be two or more blocking dialogs when there are multiple commands that need a blocking dialog. This can be solved by having an implementation of InputBlocker in the service which counts the number of commands that need the dialog up when the command is added and down when it is removed. At one the dialog is shown and at zero it is hidden. Also the SwingWorker or Task doesn’t need to maintain an input blocker because the service maintains it.
A special service can be used for deferring loading large results for lists, tables and trees. The model uses the service to lookup elements/rows or cells/nodes inside a Runnable and post the runnable to the service. The service automatically blocks the input on the user interface component when looking up an object.