Other Swing Changes

API for Adding Actions to ActionEvent Sources


Swing provides an implementation of the Command pattern which helps application developer centralize functionality which can be accessed from multiple places in the GUI. The Action interface is used to provide a stateful ActionListener which can provide the implementation of functionality accessed for example from the toolbar, a menu item, and a keyboard binding. As the state of the Action changes, for instance when it becomes disabled, the associated controls change their state accordingly (they also become disabled).

The Problem

For Actions to work as intended, the following connections need to be made (assume the Action has already been created):
  1. The control needs to be created
  2. The Action is added as an ActionListener on the control
  3. A PropertyChangeListener is created which describes how the control should be updated in response to PropertyChangeEvents on the Action
  4. The PropertyChangeListener is added as a listener on the Action.
  5. Information about the linkage may need to be retained so it can be undone to allow garbage collection (in 1.2 this can be automatically handled with WeakRefs).
Since a typical application may have between 5 and 25 Actions, and 2-3 controls per Action, the steps above need to be done up to 75 times!

In order to relieve the developer of much of this burden, we have provided a way to have this done automatically, through helper methods on potential Containers of Actions. The three places where this is surfaced in Swing at present are: public JButton add(Action a) public JMenuItem add(Action a) public JMenuItem add(Action a)

The problems with this approach are several:

  1. It is highly problematic for Builders, since it overloads Container.add() to allow a non-Component parameter which is not itself the thing that ends up being added.
  2. Developers cannot participate in the configuration of the controls created without subclassing the container classes
  3. Even if they do subclass, the granularity of the configuration ends up being per-Container instead of per-control added.
  4. It limits developers to the expected control for each Container rather than allowing the full range of ActionEvent sources which Action permits.


Many developers have commented that they would prefer to create their own controls which are ActionEvent sources and then have a method which connects them to a particular Action. The solution is along these lines, and addresses the deficiencies listed above.

The added API is initially added to AbstractButton, which defines the abstract superclass of JButton, JMenuItem, JMenu, JCheckBox, etc.

The new public methods are as follows:

In addition, constructors have been added to the ActionEvent sources which will allow for creating a control directly with the supplied Action.

In JButton:

Equivalent constructors have been added to: Notes:

createAction Factory Methods for JToolBar, JPopupMenu, JMenu

New factory methods allow one to control what toolbars and menus create when an action is added directly, i.e. with the add method.

Addition to JToolBar:

Addition to JPopupMenu: Addition to JMenu:

New Action Constants


Add AbstractAction getKeys Method

This new method is needed for serialization of Abstract Actions, and gives the developer a way to find out which keys have been set for the AbstractAction.


Copyright © 1999 Sun Microsystems, Inc. All Rights Reserved.

Please send comments to: This is not a subscription list.
Java Software