Scott Violet's Blog

Community: JDK Archives

Ease of Swing Development - Beans Binding

Beans Binding

  slider.addValueListener(new ChangeListener() {
    public void stateChanged(ChangeEvent e) {
      selectedObject.setFoo(slider.getValue());
    }
  });

  selectedObject.addPropertyChangeListener(new PropertyChangeListener() {
    public void propertyChanged(PropertyChangeEvent e) {
      if (e.getPropertyName() == null || "foo".equals(e.getPropertyName())) {
        slider.setValue(selectedObject.getFoo());
      }
    }
  });

Beans Binding aims to make it easy to bind two properties of two objects together. Taking the slider example, you might be able to bind the two together with the following code.

  bind(slider, "value", selectedObject, "foo");

Of course this is a simplified view of things, beans binding will likely accomodate converters, and possibly validators. To be successful it will also need to accomodate renderers. At this years JavaOne conference Hans and myself did a presentation on beans binding with a handful of demos. You can view the presentation here. The source for the first demo can be found here. Notice the source contains two variants, one implemented in terms of binding (BindingCaricatureController), the other with typical listeners (NoBindingCaricatureController). You can run the demo by clicking on the launch button below.

We also demoed how beans binding addresses more traditional database apps at JavaOne, but being a database app, it requires a bit more setup so I'm holding off on publishing it now. I'll return to it later on.

Data Binding

WARNING: I am not on the expert group for 227, and do not speak for Mike De Groot, the spec lead for 227. Mike was gracious enough to meet with me on various occasions to help me understand where he believes 227 is going. The following is based on those conversations, but as 227 is not finalized, it may change.

JSR 227 aims to make it easy to bind to any data, be it a ResultSet an XML service, you name it. 227 will not care about the type of your data, there will be an intermediary class used to access the data that knows the specific of your data. In this manner, assuming you have the intermediary layer, 227 will work with any data. Beans Binding is much narrower than that, it assumes you have your data in a well known type, a bean and possibly a Map. A big part of 227 includes declaratively describing the bindings and data, Beans Binding will not include a delcarative XML file describing the bindings and data.

So, why care about beans binding? If you're a good OO citizen you've already created some mapping layer from your database (or other backend) to real objects. Hibernate, Mustang's DataSet, and EJB 3 all do this; they provide a way for you to get real object graphs. Once you've done that, it'll just work with beans binding and the world will be a happier place. Ok, perhaps that's a bit grand, but at the least beans binding will simplify wiring your application objects to components.

What can you do?

    -Scott

Architecting Applications 3: the Controller

I was strongly tempted to redo the model a bit for this installment of the application architecture series, but I had to hold back lest there be no demo for this article. So, without further ado, here's the demo.

Password Store Demo Screenshot

The demo is far from complete. In particular most of the menus are not wired up and are disabled. The only menu items that work is creating a new account (control-n). I'll flesh out the implementation of the remaining menu items in future articles. Complete source code is available at the end of the article.

To keep the app from being signed, but be able to store information between sessions I'm using the persistence service provided by webstart. The persistence service allows an app to save state in a secure way, similar to cookies. If you run the app from the command line it'll save the file into your home directory.

Controller

1. Create and assemble the view.
2. Wire the view to the model or controller as appropriate.
3. Keep the view and model in sync.

Creating the UI

JList Wiring

  private PasswordModel model;
  private class PasswordListModel extends AbstractListModel {
    public int getSize() {
      return model.getPasswordEntries().size();
    }
    public Object getElementAt(int index) {
      return model.getPasswordEntries().get(index);
    }
  }

Synchronization

  // Install a DocumentListener on the host text field
  hostTF.addDocumentListener(new DocumentHandler());

  private class DocumentHandler implements DocumentListener {
    public void insertUpdate(DocumentEvent e) {
      edited(e);
    }

    public void removeUpdate(DocumentEvent e) {
      edited(e);
    }

    public void changedUpdate(DocumentEvent e) {
      // TextFields can ignore this one.
    }

    private void edited(DocumentEvent e) {
      // The host text field was edited, update the model
      hostChanged();
    }
  }

  // A valid edit has occured, update the model.
  private void hostChanged() {
    getSelectedEntry().setHost(hostTF.getText());
  }

The Controller must also track changes made to the model by other parts of the app. For example, an Action might directly update the model. To track changes to the model the Controller installs a PropertyChangeListener on each PasswordEntry. Here's the code.

  // Install a listener on each entry
  entry.addPropertyChangeListener(new PropertyChangeHandler());

  private class PropertyChangeHandler implements PropertyChangeListener {
    public void propertyChange(PropertyChangeEvent e) {
      entryChanged((PasswordEntry)e.getSource(), e.getPropertyName());
    }
  }

  private void entryChanged(PasswordEntry passwordEntry,
          String propertyChanged) {
    // Notify the list of the change
    listModel.fireContentsChanged(model.getPasswordEntries().
              indexOf(passwordEntry));

    // If the selected entry was changed, update the appropriate text field
    if (getSelectedEntry() == passwordEntry) {
      if (propertyChanged == "host") {
        hostTF.setText(passwordEntry.getHost());
      } else ...
    }
  }

The following graphically depicts changes originating from the text field.

The following depicts changes originating from the model.

What's wrong with the previous code? Turns out there is a subtle bug. When the text field changes, we update the model, which sends notification, which triggers a reset of the text field. JTextField (actually javax.swing.text.Document) does not allow a listener to modify the contents, so that this code triggers Swing to thrown an exception. Here's a graphical depiction of this.

Notice the textfield on both sides.

This is happening because the Controller doesn't realize that it initiated the change to the model and doesn't need to update the display. There are a couple of schemes for dealing with this. You can disable and reenable listeners, check the contents of the text fields, or keep a property around. I've settled for keeping a property around that tracks if the Controller initiated a change to the model.

Here's the revised code for the edited method that is invoked when the text is edited.

  private void hostChanged() {
    if (!changingHost) {
      changingHost = true;
      getSelectedEntry().setHost(hostTF.getText());
      changingHost = false;
    }
  }

The entryChanged method is similarly updated.

  private void entryChanged(PasswordEntry passwordEntry,
          String propertyChanged) {
    // Notify the list of the change
    listModel.entryChanged(model.getPasswordEntries().
              indexOf(passwordEntry));

    if (getSelectedEntry() == passwordEntry) {
      if (propertyChanged == "host" && changingHost) {
        changingHost = true;
        hostTF.setText(passwordEntry.getHost());
        changingHost = false;
      } else ...
    }
  }

The last thing worth mentioning is that as List has no notification the Controller can not listen to it. Instead all mutations to the list itself are done in Controller which will update the ListModel appropriately. I will revist this later on.

Source

Summary

    -Scott

Mustang: the little things

I'm taking a brief hiatus from my series of blogs on application architecture to join in the mustang blog carnival extravaganza that is celebrating the beta release of mustang. The bulk of the major features have already been covered. Chet and myself have covered true double buffering, Shannon has covered the dnd work, SwingWorker was covered in an article, table's sorting and filtering API was discussed as well. I've even covered some of the smaller stuff, like the action improvements. So, what to talk about?

After struggling with what to cover, I realized that some times it's not just the big things that make a release matter, but a culmination of both the big things and the little things. So, in this blog I'll cover the little bugs and features. The things that by themselves aren't that big, but undoubtedly make the release that much better.

ButtonGroup.clearSelection

Anyone that has seriously used ButtonGroup undoubtedly stumbled over the inability to clear the selection of the group. For example, lets say you have two toggle buttons in a button group and you need to clear the selection to an initial state. Previously there was no way to do this! Sure, there are some ugly workarounds, but thankfully we've addressed this problem now. In mustang we've added the method clearSelection to ButtonGroup. Funny enough this is the oldest bug we've fixed for Swing in mustang.

Justified Text

One of Swing's most voted on bugs is support for fully justified text in Swing's text components. What's doubly bad about this feature is that we've always had API that implies it would work, but it never had. Well, thankfully it now does. Here's a screen shot of Stylepad in mustang with fully justified text:

YIKES! I know, it turns out we justified the last line of the text which obviously doesn't look good. Thankfully this bug will be fixed before the final release of mustang. Here's a screenshot with the fix:

Window.setMinimumSize

Another long time sore point is the inability to enforce a minimum size for Windows. Being a long time NeXT/Apple user I've always thought it a good idea to enforce a minimum window size. That doesn't appear to be too common on Windows boxs though. None-the-less the API now works and you can set a minimum size. Here's an internal app that can't enforce a minimum size:

And that same app with mustang when it could enforce a minimum size:

Nice!

Painting offscreen components

Getting into the more niche arena, Swing's painting code has always ignored painting child components if the Component is not contained in a Window or an Applet. Why would you ever do this? Perhaps you want to render a JComponent, and it's children, to an image. This came up a number of times on the forum. Finally it's fixed! I know, a bit obscure but none-the-less interesting. See 6215148 for details.

JTextComponent printing

The last thing I'll mention is certainly not a small change. Following the JTable printing support we added in 1.5 we've now made it trivial to print text component. JTextComponent now has a print method that allows you to specify various attributes of the print job, such as header, footer... This means it's now trivial to print a text component and have the output reformatted for the page, just like a user would expect!

So anyway, if you haven't yet tried mustang I highly recommend you give it a whirl. As an incentive we announced a free t-shirt for any regressions that are found as well as the chance at winning an Ultra 20, sadly this offer isn't availble to Sun engineers;)

Next time around, more application architure.

-Scott

Architecting Applications 2: the Application class

Swing is an incredibly rich toolkit, but to date we haven't provided much guidance on how to structure your app. How should I start my app? Where should I place resource bundles in my project? How should I use preferences? Logging? ... The list goes on. While I'm not going to address all of these issues I'm going to focus on the first issue. How should I start my app? The first thing to comes to mind is something along the lines of:

public class Main {
  public static void main(String[] args) {
    JFrame frame = new JFrame(...);
    frame.pack();
    frame.show();
  }
}

We currently recommend an approach along the following lines:

public class Main {
  public static void main(String[] args) {
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        createAndShowGUI();
      }
    });
  }
}

Here's how I would like to write main:

public class Main {
  public static void main(String[] args) {
    new MyApplication().start();
  }
}

• Registering as the uncaught exception handler such that if an uncaught exception is received the application alerts the user and exits.
• Using a ResourceBundle for localized resources. For small to mid size apps putting resources into a single resource bundle is fine, large apps will undoubtedly want finer granularity.
• Using a PreferencesNode for persistant information. Again, for small to mid size apps using the same preferences nodes is fine, for large apps you will undoubtedly want finer granularity. There are problems with using preferences in webstart/plugin, but that's for another day.
• A single point to exit the app, as well as the ability for listeners to cancel the exit.
• Ability to block exiting until background threads have finished as well as displaying a dialog to the user while this is happening.

I suspect anyone that's developed a number of Swing apps has already developed a similar class. You can find the version used in this article here, or peruse the doc of Application and ApplicationListener.

Application itself is an abstract class, a typical subclass, and the one for this blog series, looks like:

public class PasswordStoreApplication extends Application {
    public String getName() {
        return "PasswordStore";
    }

    protected void init() {
        JFrame frame = new JFrame(getName());
        frame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
        frame.addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                exit();
            }
        });
        frame.pack();
        frame.setVisible(true);
    }

    public static void main(String[] args) {
        new PasswordStoreApplication().start();
    }
}

Those that look at the code will notice a couple of hard code strings. Bad Scott, bad Scott! I did this to make it easier for folks to download the source and use, but this most definitely needs to come from a resource bundle. You've been warned.

I've tried to keep Application simple. It doesn't know about Frame or any other application specific components, that's up to subclasses. In fact it probably makes sense to have a subclass that knows about a single frame. Such a subclass would further reduce the code of PasswordStoreApplication as registering the window listener, packing and all that would be done for you.

One of the biggest open questions with a class like Application, is should it do dependency injection? That is, should Application contain meta information about your application that can be used in configuring it. For example, database style apps need to know what database to connect to. Does it make sense to have Application configure your connection settings so that there is a standard place for this meta information? I'm not sure, but I'm certainly interested in feedback from the community.

A related issue I mentioned is how this class would work with builders. Ideally one would be able to create a 'Swing Application' which in turn would configure things like the name of the application and perhaps a class to create on the EDT. In this way developers needn't subclass Application directly, the builders would do the wiring for you. More research is needed on this.

Hans suggested rather than using listeners you have the ability to register Runnables given a name, with the Runnables processed at well known points in the app life cycle. This would make for a more loosely specified init sequence, but one that allows for a bit more than listeners. I'll explore this in more detail later.

In the interest of keeping each blog short and sweet I'm going to wrap this one up here. I had hoped to have something running by this point, but I'll leave that to the next blog. In the next blog I'll create a controller class along with the UI that ties the model together and is started with the Application subclass. I promise that by the end of the next article you'll be able to click on a web start link to see the app running.

    -Scott

Architecting Applications 1: the model

As part of the series I'll cover architecting the app (this blog) including using beans persistence as a way to save the model, Actions, Undo, the need for an application class, data binding and various other things that come up.

In writing a series of blogs around an app I thought it important that the app be compelling enough, but not too big such that you become bogged down in all the implementation details. So, I needed something small but not too small as to be trivial. I may have erred on the side of trivial, none-the-less the concepts and points are still worth while to explore.

If you're like me you have a ton of passwords for various machines and web sites that you're expected to remember. As an added wrinkle each password should be unique and unreadable, ugh! Added together this makes it nearly impossible to remember all your passwords. For this series I'm going to stick with a simple app that manages passwords. A Java based app that stores passwords has the added bonus of being able to run from a USB memory stick on the three major platforms: Windows, OS X and Linux. I realize there are loads of commercial apps in this space that undoubtedly go way beyond what I'm going to do. None-the-less such an app is at least interesting and not too complicated (at least as far I'm going to take it).

Here's roughly where I'll end up when done with the series:

A password store will need to be encrypted, I'm going to leave that out as I don't want to worry about the legal issues of such a blog.

There are various approaches to designing apps. Some of the more popular patterns are model-view-presenter , presentation model and model-view-controller. I'm a fan of the latter, and especially for an app of this size. In creating any app you'll need to make the desicision as to which approach is applicable to your design space and requirements.

Model-View-Controller dictates that you have a clear model for your application. The Controller coordinates keeping the view and model in sync. The model for Password Store is going to be trivial. It'll consist of a List of PasswordEntrys. Each PasswordEntry will have the following properties: host, user and password. PasswordEntry will be a proper bean in that it'll communicate changes to listeners by way of a PropertyChangeListener notification. That means any time you change a property all PropertyChangeListeners are notified of the change. Here's the code for setting the host property:

    public void setHost(String host) {
        String oldHost = this.host;
        this.host = host;
        if (propertySupport != null) {
            propertySupport.firePropertyChange("host", oldHost, host);
        }
    }

The List of PasswordEntrys will be managed by a PasswordModel. PasswordModel will initially expose the List as modifiable. I suspect this is a bad long term decision, but I'm going to stick with it in hopes of keeping the API simple and not getting bogged down in details. Here's the code:

public class PasswordModel {
    private List passwordEntries;
    
    public PasswordModel() {
        passwordEntries = new ArrayList(1);
    }
    public List getPasswordEntries() {
        return passwordEntries;
    }

An added bonus of making the PasswordEntrys proper beans is that I can save and restore the PasswordEntrys using beans persistence. Here's the code:

    public void load(String file) throws IOException {
        BufferedInputStream inputStream = new BufferedInputStream(
                new FileInputStream(file));
        XMLDecoder decoder = new XMLDecoder(inputStream);
        List entries = (List)decoder.readObject();
        decoder.close();
        passwordEntries.clear();
        passwordEntries.addAll(entries);
    }
    
    public void save(String file) throws IOException {
        BufferedOutputStream outputStream = new BufferedOutputStream(
                new FileOutputStream(file));
        XMLEncoder encoder = new XMLEncoder(outputStream);
        encoder.writeObject(passwordEntries);
        encoder.close();
    }

    -Scott

Variations of JPasswordField

Variation 1: no feedback

  passwordField.setEchoCharacter('\u200b');

Variation 2: variable amount of space

All of Swing's text components, be it JPasswordField, JTextField, JEditorPane share the same architecture. What applies to one equally applies to the others. The text component use an instance of View to do the rendering of text. In some ways a View can be thought of as a lightweight Component, for example, View has methods like getPreferredSpan, getMinimumSpan, paint... Just as Containers are typically nested Views are usually nested as well. Views are responsible doing the following:

• Layout of either text or child Views. This includes calculating a size for the View.
• Painting.
• Provide a mapping between model and view, or view and model. For example, what position on screen is the character at location 5 in the model.
• Updating as the model changes.

    private static final int MIN_WIDTH = 2;
    private static final int MAX_WIDTH = 15;

    private List<Integer> widths;
    private Random widthGenerator;

    private final int generateCharacterSize() {
        return widthGenerator.nextInt(MAX_WIDTH - MIN_WIDTH) + MIN_WIDTH;
    }

    // Invoked when text has been inserted. Updates the width List appropriately
    public void insertUpdate(DocumentEvent changes, Shape a, ViewFactory f) {
        for (int i = 0; i < changes.getLength(); i++) {
            // Notice the autoboxing of int to Integer here.
            widths.add(i + changes.getOffset(), generateCharacterSize());
        }
        // Invoke super to update the visibility appropriately.
        super.insertUpdate(changes, a, f);
    }

VariableWidthPasswordView doesn't need to paint, so it no-ops the appropriate paint methods. The primary View method for painting is paint. VariableWidthPasswordView is a subclass of FieldView which implements paint to invoke drawSelectedText and drawUnselectedText. VariableWidthPasswordView will override drawSelectedText and drawUnselectedText to do nothing. This is done rather than overriding paint as paint is also responsible for invoking the appropriate methods to render the selection. By overriding drawUnselectedText and drawSelectedText to do nothing the selection is still rendered appropriately by FieldView.

To map from a position of text in the model to that of the view VariableWidthPasswordView overrides modelToView. modelToView uses the List of widths to determine the position. Here's the implementation:

    public Shape modelToView(int pos, Shape a, Position.Bias b)
            throws BadLocationException {
        // JPasswordField and JTextField implement their own virtual
        // coordinate system. This does the necessary mapping.
        Rectangle bounds = adjustAllocation(a).getBounds();
        bounds.x += modelToView(pos);
        bounds.width = 1;
        return bounds;
    }
    // Returns the view x coordinate in the views space for the specified
    // model coordinate.
    private final int modelToView(int p1) {
        int offset = 0;
        int end = Math.min(widths.size(), p1);
        for (int i = 0; i < end; i++) {
            // Notice the auto unboxing here.
            offset += widths.get(i);
        }
        return offset;
    }

    public int viewToModel(float fx, float fy, Shape a, Position.Bias[] bias) {
        a = adjustAllocation(a);
        Rectangle bounds = (a instanceof Rectangle) ? (Rectangle)a : a.getBounds();
        int x = (int)fx - bounds.x;
        for (int i = 0; i < widths.size(); i++) {
            // More auto unboxing.
            x -= widths.get(i);
            if (x <= 0) {
                return i;
            }
        }
        return getEndOffset();
    }

    public float getPreferredSpan(int axis) {
        if (axis == View.X_AXIS) {
            int size = 0;
            for (Integer width : widths) {
                size += width;
            }
            return size;
        }
        return super.getPreferredSpan(axis);
    }

   // We generally discourage using UIs from one look and feel
   // with another look and feel. When using metal this will be fine,
   // that may not be true when using other look and feels.
   JPasswordField myPasswordField = new JPasswordField(10) {
        public void updateUI() {
            setUI(new BasicPasswordFieldUI() {
                public View create(Element elem) {
                    return new VariableWidthPasswordView(elem);
                }
            });
        }
    };

1: As this demo shows it's possible to write a UI that ignores the echo character. All of Sun's UIs honor the echo character, but third party look and feels may not.

Changes to Actions in 1.6

In 1.6 we've overhauled Actions adding new features and fixing a handful of annoying bugs. For this blog I'm going to cover the new features and when you might use them.

Action.SELECTED_KEY

The single biggest request for Actions was to add support for Actions to represent selected state. In particular when an Action is attached to a JRadioButton, JCheckBox, JToggleButton and the like there was no way to change the selected state of the component from the Action and have it reflected in the component. The new key Action.SELECTED_KEY takes care of that. All components that visually represent a selection will now listen for changes to the SELECTED_KEY and reflect that in the component.

The following code creates a JRadioButton from an Action that is initially selected:

  Action action = new MyAction();
  // Make the action selected. 
  action.putValue(Action.SELECTED_KEY, Boolean.TRUE);
  JRadioButton selectedRadioButton = new JRadioButton(action);

The following example shows how an Action could customize it's behavior based on the selected state:

  class BoldAction implements Action {
    public void actionPerformed(ActionEvent e) {
      toggleBold((Boolean)getValue(Action.SELECTED_KEY));
    }
  }

Action.LARGE_ICON_KEY

All buttons and menu items have the ability to show an Icon. When a button or menu item is associated with an Action the button or menu item uses the Icon from the Action. This is problematic because typically you want two different icons for these two components. To address this in 1.6 we added LARGE_ICON_KEY. Menu items will only use the Icon from the SMALL_ICON property. Buttons will first look for the LARGE_ICON_KEY property, if it's value is non-null it will be used, otherwise the value from SMALL_ICON is used. This enables you to customize the Icon for the two different components.

The following example creates an Action with two different icons. The menu item will use smallIcon and the button largeIcon:

  Action action = new MyAction();
  action.putValue(Action.SMALL_ICON, smallIcon);
  action.putValue(Action.LARGE_ICON_KEY, largeIcon);
  // menu item will use smallIcon
  new JMenuItem(action);
  // button will use largeIcon
  new JButton(action);

Action.DISPLAYED_MNEMONIC_INDEX_KEY

  Action action = new MyAction();
  action.putValue(Action.NAME, "Save As");
  // Notice the autoboxing here.
  action.putValue(Action.MNEMONIC_KEY, KeyEvent.VK_A);
  action.putValue(Action.DISPLAYED_MNEMONIC_INDEX_KEY, 5);
  new JMenuItem(action);

AbstractButton.setHideActionText

  Action action = new MyAction();
  action.putValue(Action.NAME, "Save As");
  new JMenuItem(action);
  JButton toolbarButton = new JButton(action);
  // We don't want the button to mirror the text from the Action.
  toolbarButton.setHideActionText(true);

System property swing.actions.reconfigureOnNull

This property is useful for cases where you want to do a bunch of changes to an Action without sending individual property changes, and then have all listeners refetch properties when done. I honestly can't say I have ever had a need for this functionality, but it's now there.

The javadoc for Action now details all this information as well as how the various components support the different Action properties.

As usual, if you want to try out these changes (and the rest of the goodness in 1.6) download the source and binaries from mustang snapshot release.

The Usefulness of Actions

I originally intended to blog on the usefullness of WeakReferences for
client apps. This was to be motivated by the internals of Actions and
why Swing internally needs to use a WeakReference to support
Actions. In writing that blog I ended up spending more time describing
Actions that I've decided to split it into two blogs. This blog
motivates the need for Actions as well as the changes to Actions
in 1.6. Later on I'll followup with why we use WeakReferences to
support Actions and why you might use WeakReferences in similar
situations.

An ActionListener encapsulates application specific functionality that
is usually triggered by a user interface gesture (this isn't always
true, javax.swing.Timer also uses ActionListener). For example
clicking the back button in a browser might notify an implementation
of ActionListener this is responsible for navigating to the previous
page. This might look something like:

private class GoBackActionListener implements ActionListener {
  public void actionPerformed(ActionEvent e) {
    browserComponent.show(getLastURL());
  }
}
backButton.addActionListener(new GoBackActionListener());
backButton.setIcon(...);
backButton.setEnabled(false);

If you've written any Swing/AWT application chances are you have code
like this. It's simple, and it works.

Consider what happens if you want to conditionally enable the button
based on whether you can go back a page. In this case you need a
handle to the backButton so that you can invoke setEnabled on
it. If you also have a menu item with the same functionality you'll
need to keep a handle to that menu item as well, or any other user
interface component that is to use the GoBackActionListener
functionality. This is a bit painful. In particular it leads to all
sorts of references back to the hosting components in your application.

The following code shows configuring a menu item and wiring it to a
GoBackActionListener:

backMenuItem.addActionListener(new GoBackActionListener());
backMenuItem.setText(...);
backMenuItem.setMnemonic(...);
backMenuItem.setDisplayedMnemonicIndex(...);
backMenuItem.setAccelerator(...);
backMenuItem.setEnabled(false);

The Action interface is meant to address these problems. Action not
only encapsulates the functionality part of ActionListener, but also a
description of that functionality as appropriate for user interface
components. Included in that description is whether or not the user
interface component should be enabled. When the enabled state of the
Action changes the user interface components listening to the Action
will update appropriately. If the previous examples were replaced
with Action you would change the enabled state of the Action, and as
a consequence the button and menu item would update appropriately. The
code for this could be something like:

private class GoBackAction extends AbstractAction {
  public GoBackAction() {
    putValue(Action.NAME, "...");
    putValue(Action.LARGE_ICON_KEY, ...);
    putValue(Action.SMALL_ICON, ...);
    putValue(Action.MNEMONIC_KEY, ...);
    putValue(Action.DISPLAYED_MNEMONIC_INDEX_KEY, ...);
    putValue(Action.ACCELERATOR_KEY, ...);
    putValue(Action.SHORT_DESCRIPTION, ...);
    setEnabled(false);
  }
  public void actionPerformed(ActionEvent e) {
    browserComponent.show(getLastURL());
  }
}
Action goAction = new GoBackAction();
backButton.setHideActionText(true);
backButton.setAction(goAction);
backMenuItem.setAction(goAction);

You'll notice a number of differences with this example and the
earlier ones. In particular rather than configuring the text, icon and
other properties of the user interface component the Action contains
all this information. When the Action is attached to the user interface
component the user interface component configures its state from the
Action. For buttons this includes the icon, text, mnemonic, mnemonic
index, tooltip text, action command key and enabled state. This is
nice in that the description is encapsulated in a single place and
does not need to be replicated to all the hosting components.

Those that haven't followed the latest changes in 1.6 will notice some
new keys and methods. In particular DISPLAYED_MNEMONIC_INDEX_KEY,
LARGE_ICON_KEY and setHideActionText are all new in 1.6. Action got
one more new key in 1.6, that is SELECTED_KEY. Included in the 1.6
additions is centralizing the description of what properties each
component supports. See the class level javadoc of Action for all the
specifics, as well as bugs 4133141 and 4626632.

When using ActionListener we had to explicitly update the enabled
state of the user interface components, eg:

backButton.setEnabled(...);
backMenuItem.setEnabled(...);

With Action the code becomes:

goBackAction.setEnabled(...);

Any user interface components attached to the Action will update
appropriately whenever the Action changes! Now we just reference the
Action and not all the various components.

The ability to change the Action directly and have it reflected
appropriately in the user interface component comes in very handy in a
number of situations. For example, undo/redo menu items often have
their text reflect what the undo/redo operation will do. For example,
'Undo Paste' or 'Undo Edit'... When using Action you change the NAME
property of the Action and the menu item will change appropriately.

If this is the first time you've read about Actions you should read
the Swing tutorial section on Actions. It has more examples and
details. In a later blog I'll cover using the new SELECTED_KEY. It's
interesting enough that it warrants it's own blog.

Matisse: one step closer to cross platform layout nirvana

Baseline support

Preferred Gap

GroupLayout

Do we really need to wait for Mustang to use this?

This work is licensed under a Creative Commons License.