Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java Tip 142: Pushing JButtonGroup

Build a better ButtonGroup

By Daniel Tofan, JavaWorld.com, 09/19/03

Note: You can download this article's source code from Resources.

ButtonGroup holes

Here's a common scenario in Swing GUI development: You build a form to gather data about items that someone will enter into a database or save to a file. The form might contain text boxes, check boxes, radio buttons, and other widgets. You use the ButtonGroup class to group all radio buttons that need single selection. When the form design is ready, you start to implement the form data. You encounter the set of radio buttons, and you need to know which button in the group was selected so you can store the appropriate information into the database or file. You're now stuck. Why? The ButtonGroup class does not give you a reference to the button currently selected in the group.

ButtonGroup has a getSelection() method that returns the selected button's model (as a ButtonModel type), not the button itself. Now, this might be okay if you could get the button reference from its model, but you can't. The ButtonModel interface and its implementing classes do not allow you to retrieve a button reference from its model. So what do you do? You look at the ButtonGroup documentation and see the getActionCommand() method. You recall that if you instantiate a JRadioButton with a String for the text displayed next to the button, and then you call getActionCommand() on the button, the text in the constructor returns. You might think you can still proceed with the code because even if you don't have the button reference at least you have its text and still know the selected button.

Well, surprise! Your code breaks at runtime with a NullPointerException. Why? Because getActionCommand() in ButtonModel returns null. If you bet (as I did) that getActionCommand() produces the same result whether called on the button or on the model (which is the case with many other methods, such as isSelected(), isEnabled(), or getMnemonic()), you lost. If you don't explicitly call setActionCommand() on the button, you don't set the action command in its model, and the getter method returns null for the model. However, the getter method does return the button text when called on the button. Here is the getActionCommand() method in AbstractButton, inherited by all button classes in Swing:

    public String getActionCommand() {
        String ac = getModel().getActionCommand();
        if(ac == null) {
            ac = getText();
        }
        return ac;
    }

This inconsistency in setting and getting the action command is unacceptable. You can avoid this situation if setText() in AbstractButton sets the model's action command to the button text when the action command is null. After all, unless setActionCommand() is called explicitly with some String argument (not null), the button text is considered the action command by the button itself. Why should the model behave differently?