Previous column

Next column

Project Imperion: New Semantics, Façade and Command Design Patterns for Swing

Douglas Lyon, Computer Engineering Department, Fairfield University, Connecticut, USA

space COLUMN

PDF Icon
PDF Version

…Thus in the beginning the world
was so made that certain signs
come before certain events
- Cicero. 106–43 B.C.


Project Imperion consists of a library of GUI elements that combine the command and facade design patterns to add new semantic meaning to some common Swing components. This simplifies the synthesis and maintenance of the code. It also shortens the code, while improving readability, speeding synthesis and easing maintenance. It also promotes better code organization, including the separation of business logic from GUI code and a logical grouping of the code along the same lines as its GUI’s appearance.

Started in the late ‘90’s, in the DocJava, Inc. Skunkworks, the Imperion project was meant only for menu items using AWT, targeting the single application of image processing programs. It has since been reworked and extended to support the use of 16 Swing components with built-in keyboard shortcuts. The Imperion project was named for the Latin root, imperium, meaning the power to command.


When programmers use the current event model, they typically jump around in the source code. For example, it is normal for programmers to create a graphic user interface using a 5 step process:

  1. Make a new button (or Component)
  2. Set the keyboard shortcuts.
  3. Add the button to the container.
  4. Add an ActionListener to the button
  5. Create a long dispatch in an actionPerformed method.

Visiting code in several places in order to add a feature is a fruitful source of errors. The code is also hard to maintain, and less readable in that the programmer must jump back and forth in the code file to see declarations, installation of components into GUI containers and implementations of event listeners.

Such an approach does not scale well. When the number of different components gets large, these jump points can be many lines of code away from one another. To illustrate the programmers’ jumping around in the code, consider the following example:

Thus, the typical procedure is to put an instance of a button into a class member variable. During the initialization phase for the GUI, the shortcuts are established, components are added to the container and the listeners are added. During the event handling dispatch we check the event to see if it the button was selected. As a result, we have created a situation where we have to visit the code in several places. This complicated procedure for adding code also complicates maintenance and decreases reliability of the program. It also adds more code. The output of the CommandFrame is shown in Figure 1.

Figure 1. OK-Cancel Dialog.

In addition, using the above formulated actionPerformed method, one can expect a rather long dispatch. As an example, consider the following code, taken from [Lyon 1999]:

Such long dispatches can be exceedingly difficult to maintain. And GUI elements are removed from their definitions by hundreds of lines of code (in programs of only modest complexity). Even more insidious is the invocation:

This can make reference to an unknown number of concrete super-classes that improve implementation reuse at a cost of increased fragility. In short, such a programming style does not scale well because it does not encapsulate complexity at the right level. The following section shows that adding function points in this way is a waste of time (i.e., unnecessarily difficult and wrong-headed).

If you don’t
have time to do it right
the first time, when
will you have time to
do it again?

– Unknown


This section presents an approach to building the same program by creating a new, more feature-rich button, called the RunButton. A RunButton instance is a button that knows how to run itself. Such a button makes use of what is known as the command design pattern. The command design pattern places an instance of a command into an instance of another class, call the issuer. For example, a button can have the role of the issuer, holding a reference to an instance of a command. Thus a RunButton will invoke a command (run()) on the command instance. The command instance has the role of either message forwarding the command to a specific recipient or of executing the command itself.

We define the RunButton class as a subclass of the JButton class. It works using the façade design pattern to map the ActionListener interface into the simpler Runnable interface. The run method is left undefined and this causes the class to be abstract.

The main method in the above code sample also produced Figure 1.


The astute reader may ask, “why start using non-standard GUI elements in the code? What’s so wrong with using the command pattern without altering the interface from an ActionListener to a Runnable?” The primary problem is that there are just too many listeners to keep track of. As of j2se1.4.2, there are 68 known different interfaces that extend the java.util.EventListener interface. There are 234 known implementations of these interfaces in a wide variety of classes. This is too much complexity for the average programmer to keep in their head.

Using the Facade design pattern we are able to map several common components to take advantage of the simpler Runnable interface, as shown in Figure 2.

Figure 2. Some Run Components

One of the basic questions that we must ask of a framework is: “how much complexity is too much?” If a feature set overwhelms us, then we no longer have the ability to program without constantly consulting documentation. This is a burden to the programmer. In short, simplicity is a desirable feature. By mapping several of the interfaces to the simpler Runnable interface, we can simplify our code. We dispense with the ability to obtain the target of the event, but, since the GUI element always knows that it is its’ own target, it no longer needs these parameters. Thus, we have made a design decision to always make use of the command pattern when invoking GUI elements in the Imperion project.


Keyboard shortcuts are often added to an interface as an afterthought. In fact, a GUI is really just a visual language for commanding a program. Adding more GUI elements to add more commands (i.e., feature points) is common practice. Programmers often ask, “Do we really need keyboard shortcuts too?”. There are compelling reasons to add keyboard shortcuts, and to make these as easy as possible for the programmer to maintain them.

Screen space is consumed as a function of the number of displayed GUI elements. Even pop-up menus consume valuable screen space and make selection difficult. For example, menus with more than 10 items make scanning a list tedious. Also, many of the items may be irrelevant to the users’ current need [Laurel]. This is the primary motivation for the use of a hierarchic menu. A hierarchic menu allows a grouping of items into relevant sub-menus. The danger is that the hierarchical menu becomes so deep that the user gets lost. According to Tognazzini, the hierarchical menu offers hundreds of extra options, but it takes much longer for the user to make a selection. Additionally, Tognazzini says that menu selections are generally faster than keyboard shortcuts [Tog].

As a result, it is common to associate keyboard shortcuts with GUI elements. This enables the user to decide how to invoke a process. It also can lead to faster execution of application commands by skilled users.


At present, a programmer must isolate a reference to a GUI element and explicitly make an instance of a Keystroke that will be associated with the GUI element. Consider the following code fragment:

The RunButton instance is stored in the sleepButton variable. This variable is needed so that the programmer can explicitly set the mnemonic that will be associated with a button press. Such a programming practice requires that a new variable be introduced for each GUI element, and that it be explicitly named by the programmer. These variables have a nasty habit of propagating through the program, adding both code and complexity.


This section shows how the Imperion project adds keyboard shortcuts to GUI elements by modifying their in-line text. Consider the following code sample:

The new RunButton has an implicit mnemonic s. The rule is that the first character after the ‘[‘ will be the mnemonic keyboard shortcut for the Imperion component. Also, that the meta-character ‘[‘ will be stripped from the final appearance of the component. The following example also produces the image shown in Figure 1:

A mnemonic shortcut always uses a meta character (this is not true for keyboard accelerators). For example, on Windows or a mac, the meta character is the ‘alt’ key. Thus, to issue the ‘OK’ command, the user types: “alt-o”. The mnemonic shortcuts are only active in a context. Thus, in a hierarchic menu system, only the visible mnemonics are active. This facilitates navigation of the menus.

Mnemonic shortcuts are different from keyboard accelerators in that accelerators do not require a meta-character and they can be invoked from any context. Thus, keyboard accelerators map to visual commands in a global way. The advantage of global invocation is that you can issue commands with fewer keystrokes. The disadvantage of global invocation is that it is easier to have conflicting accelerators in the interface. For example, multiple menu items can map to the same accelerator. In such a case, the last one to be added to the GUI is the one that gets executed. In the Imperion system accelerators are defined with the begin curly brace ‘{‘ and the end curly brace ‘}’.

Figure 3. RunMenuItems with Mnemonics and Accelerators

Figure 3 shows that the key strokes “ctrl-c” will draw a circle, but that “ctrl-C” will do a cut. Also, these keystrokes may be used from anywhere in the frame. Compare this with the context sensitive mnemonics that require the user type “alt-e,d,c” to obtain a circle. While more keystrokes are involved, the hierarchic nature of the mnemonics enables the organization of keystrokes according to their function. Global keyboard accelerators are more likely to collide than mnemonics. Collisions create semantic errors. For example, if “ctrl-c” was used for both the cut and the circle commands, it would only invoke the command associated with the keystroke added last. It should probably be a run-time error to add duplicate keystrokes, but Imperion will not catch the error, at present (nor, for that matter, does Swing). The following code will set up the GUI depicted in Figure 3:

One important feature of the code is that the visual organization of the menus and menu items is reflected in the structure of the code. That is, one does not have to guess what the function of the getDrawMenu is. A logical grouping of menu item constructions into menu factory methods improves maintainability and readability. The use of the anonymous inner classes promotes short method bodies (since people don’t generally like to see long anonymous inner classes). The short method bodies, in turn, promote method forwarding to the business logic (improving code reuse and promoting the separation of GUI code and business logic).


This section describes the Imperion technique for modifying the keyboard shortcut used on a component. Consider the following constructor for the RunMenuItem:

At the heart of the mechanism is the invocation to ShortcutUtils.addShortcut.

The addMnemonic will scan for the mnemonic meta character (i.e., ‘[‘) and add the following character as a mnemonic, if the meta character is present. The addMnemonic method is implemented as:

The basic idea is that hasMnemonic will return true only if there is a ‘[‘ present and there is a character following it. If both these conditions are met, then the character is stripped out and used to add a mnemonic. The label on the component is then reset.


The use of the command and facade design patterns to formulate a new GUI library is not new. In fact, this was described in detail in my most recent book [Lyon 2004]. The embedding of keyboard shortcuts into the text of GUI elements using a code is not new either [Lyon 1999].

However, the combination of the facade and command patterns, along with the embedding of keyboard shortcuts into the text of GUI elements, is new.
A logical grouping of menu item constructions into menu factory methods improves maintainability and readability. The use of the anonymous inner classes promotes short method bodies (since people don’t generally like to see long anonymous inner classes). The short method bodies, in turn, promote method forwarding to business logic (improving code reuse and promoting the separation of GUI code and business logic).

One of the drawbacks of the Imperion system is that the components map their actions to only a single listener (themselves). This would seem, on the surface, to be a big limitation. For example, what if many components are interested in a text-field action? I suggest that if this occurs, we are too tied to the components. That text-field should be treated as a controller in a model-view-controller design pattern. A control should alter a model. Views that are interested in the model should be observing the model, not the controller. It should come as no surprise, therefore, that having components listen to their own event is an easy limitation to live with. In fact, I contend that this is preferable, as it limits inter-object associations, which is, in my view, a primary metric of object-oriented complexity.

Another limit of Imperion (and of Swing, for that matter) is that the semantic error of duplicate keyboard accelerators is not caught. To catch the duplicates, you need code that goes to the root of the content pane and then forms a list of all accelerators in all components. Overcoming this limitation requires addressing some open questions. For example: what is the policy for accelerator duplication? That is, should we throw a run-time exception, put up a dialog box, print a warning to the console, etc. Also at question is the issue of responsibility. Sun has already made it the implicit responsibility of the programmer to check for conflicts during the test phase of the development. Since conflict checks are time consuming for the programmer, perhaps an optional display feature (with a nice GUI) would not be amiss. In any case, this remains a topic of future work.


[Laurel] The Art of Human-Computer Interface Design, edited by Brenda Laurel, Addison Wesley, 1990.

[Lyon 1999] Douglas A. Lyon. Image Processing in Java, Prentice Hall, 1999. Available from

[Lyon 2004] Douglas A. Lyon. Java for Programmers, Prentice Hall, 2004. Available from

[Tog] Bruce Tognazzini. Tog on Interface, Addison Wesley, 1992.



About the author


After receiving his Ph.D. from Rensselaer Polytechnic Institute, Dr. Lyon worked at AT&T Bell Laboratories. He has also worked for the Jet Propulsion Laboratory at the California Institute of Technology. He is currently the Chairman of the Computer Engineering Department at Fairfield University, a senior member of the IEEE and President of DocJava, Inc., a consulting firm in Connecticut. E-mail Dr. Lyon at His website is

Cite this column as follows: Douglas Lyon: “Project Imperion: New Semantics, Façade and Command Design Patterns for Swing”, in Journal of Object Technology, vol. 3, no. 5, May-June 2004, pp. 51-64.

Previous column

Next column