Creating Actions with AbstractAction

Up to now, a push button in a Java GUI has probably been built in a familiar way. You create it with a text label, then attach an ActionListener that runs when the user presses it. That approach works well for a single button. This article introduces a second route: you package the behavior into an Action object first, and then hand that same object to a button. As you will see, the same object can also be handed to a menu item, and one change made to the Action will reach every component built from it.

Before reading any explanation, look at the declaration below and ask yourself one question: when a button built from clearAction is pressed, which part of this declaration does the work? Keep your answer in mind. The rest of the article unpacks it.

Think of an Action as more than a single method. It bundles descriptive information with behavior. The name is the text a user sees for the action. The icon is a picture that represents it. The enabled property records whether the action is currently available or unavailable. These properties describe the action as something a user can see and control, separate from the code that runs when the action fires.

This bundling is why the Action idea is useful. The same object carries a label, an icon, and an enabled state, so any component that uses the action can present itself consistently. Notice that the properties belong to the action, not to one particular button. That distinction matters once you see that a button is only one of the things that can use an action. A menu item can use it too.

The declaration from the introduction does three things at once. It declares a variable of type Action named clearAction. It calls the AbstractAction constructor with the text Clear. And it opens a braced body that defines a subclass, which is what makes this an anonymous inner class. The source describes this pattern as the usual way to define actionPerformed, because it keeps the behavior right next to the place where the action is created.

AbstractAction is an abstract class that implements the Action interface. Because it implements Action, every AbstractAction object is also an Action, and that is the type a button needs in order to accept it. The class includes one method that matters most here: public void actionPerformed(ActionEvent evt). AbstractAction declares this method, but a concrete subclass must define it. In other words, AbstractAction supplies the structure, and the programmer supplies the behavior that runs when the action is performed.

Inside the braces, actionPerformed calls display.clear(). The source assumes display is an object with a clear() method. The behavior is therefore an ordinary method call, written inside the anonymous subclass. The button does not contain that call. A JButton can be created with a constructor that takes an Action object, so the button uses the behavior defined in that action rather than a separate listener attached afterward.

The source states that a JButton and a JMenuItem can both be constructed from an Action. The program below creates one Action object and hands that same object to a button and to a menu item. Read it focusing on which object is passed where. The two components are two presentations of the same Action.

Enabling, disabling, and renaming an Action update every component built from it. The enabled state belongs to the Action, so setting it to false changes every linked component. The name works the same way. The NAME property belongs to the Action, so changing it updates the text of every component built from that Action. The before and after versions below show only the rename, and the surrounding code is unchanged.

Once the components are created, you may stop keeping variables that point to them. Any later change you want to make, such as enabling, disabling, or renaming, can be done on the Action object alone. The source states that you can do everything you need to do by manipulating the Action object. This means the references clearButton and clearItem are not needed for later changes.

Java programmers often reach for lambda expressions to shorten code, so it is natural to wonder whether the anonymous class above could become a lambda. The source addresses this directly: you cannot use a lambda expression here, because Action is not a functional interface. A lambda expression can only stand in for an interface that has a single abstract method, and Action does not qualify. The deeper reason is that the anonymous subclass does more than supply a method. It also passes the name Clear to the constructor, and a lambda has no way to supply the stored properties of an Action.