JDK-5026829 : The behaviour of certain components in combination with Actions is inconsistent.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2004-04-05
  • Updated: 2005-08-11
  • Resolved: 2005-08-11
Related Reports
Duplicate :  
JDK-4626632 - Various containers for Action throw NPE when PropChgEvent has null newValue
Description
Name: gm110360			Date: 04/05/2004


FULL PRODUCT VERSION :
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Ant 1.6

A DESCRIPTION OF THE PROBLEM :
The behaviour of certain components in combination with Actions is inconsistent.

The following properties are initialized by the given Action but not updated if the property changes.
(all in all 20 bugs)

JMenuItem / JCheckBoxMenuItem / JRadioButtonMenuItem:
- Action.ACCELERATOR_KEY / Accelerator
- Action.ACTION_COMMAND_KEY / ActionCommand
- Action.SHORT_DESCRIPTION / ToolTipText

JMenu:
- Action.ACTION_COMMAND_KEY / ActionCommand
- Action.SHORT_DESCRIPTION / ToolTipText

JCheckBox / JRadioButton:
- Action.MNEMONIC_KEY / Mnemonic

JMenu.add(Action a):
- Action.ACCELERATOR_KEY / Accelerator
- Action.MNEMONIC_KEY / Mnemonic
- Action.SHORT_DESCRIPTION / ToolTipText

JPopupMenu.add(Action a):
- Action.ACCELERATOR_KEY / Accelerator
- Action.MNEMONIC_KEY / Mnemonic
- Action.ACTION_COMMAND_KEY / ActionCommand
- Action.SHORT_DESCRIPTION / ToolTipText


Additionally there is another inconsistency concerning JCheckBoxMenuItem and JRadioButtonMenuItem
compared with their non-MenuItem counterparts:
- Action.SMALL_ICON is ignored by JCheckBox/JRadioButton but is honored by the respective MenuItems.

JButton, JToggleButton, JTextField and JComboBox work as expected
(they update their state appropriatly if properties of the Action change).

The root of the problem is located in the fact that initialization and update of the components attributes
is currently separated and essentially a copy-paste resource.

You can download jUnit testcases at http://www.huxhorn.de/java_bugs/action/action_bugs.zip .
They are contained in the package de.huxhorn.bugs.action.

See the package de.huxhorn.bugs.action.fixed for a different approach. It contains fixes for the
20 failing tests by using the same class to initialize and update the component.
The ActionChangeListener inheritance hierarchy mimics the inheritance of the related components.

AbstractButton.configurePropertiesFromAction(Action a, String[] types) should probably be
deprecated since it encourages an initialization different from the update process
(the behaviour of the ActionChangeListeners propertyChange-Method).

It could still be implemented using my approach if an attribute like
'ComponentActionChangeListener actionChangeListener' has been initialized with the result
of createActionPropertyChangeListener.
It could be implemented in either JComponent or AbstractButton by simply executing
actionChangeListener.initComponentFromAction(a, types);

protected void configurePropertiesFromAction(Action a) would be implemented by executing
actionChangeListener.initComponentFromAction(a, null);

At the moment (in my fix) a listener is created just for initialization and without attaching it to the Action.


RFE concerning the documentation of Action:
    /**
     * [...]
     * Swing components expect an instance of interface <code>Icon</code> as the value of this property.
     */
    public static final String SMALL_ICON = "SmallIcon";

    /**
     * [...]
     * Swing components expect an instance of <code>Integer</code> as the value of this property.
     * @see KeyEvent
     */
    public static final String MNEMONIC_KEY="MnemonicKey";

This additional type-information may be omitted for Action.NAME,
Action.SHORT_DESCRIPTION, Action.LONG_DESCRIPTION and Action.ACTION_COMMAND_KEY
since it's probably obvious enough that Strings are expected... maybe.


Related bugs:
http://developer.java.sun.com/developer/bugParade/bugs/4765360.html
http://developer.java.sun.com/developer/bugParade/bugs/4491747.html


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
You can download jUnit testcases at http://www.huxhorn.de/java_bugs/action/action_bugs.zip .
They are contained in the package de.huxhorn.bugs.action.

See the package de.huxhorn.bugs.action.fixed for a different approach. It contains fixes for the
20 failing tests by using the same class to initialize and update the component.

Simply call ant after extraction.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Properties that are initialized from the Action at construction time should be updated in the component if they change in the Action.
ACTUAL -
The following properties are initialized by the given Action but not updated if the property changes.

JMenuItem / JCheckBoxMenuItem / JRadioButtonMenuItem:
- Action.ACCELERATOR_KEY / Accelerator
- Action.ACTION_COMMAND_KEY / ActionCommand
- Action.SHORT_DESCRIPTION / ToolTipText

JMenu:
- Action.ACTION_COMMAND_KEY / ActionCommand
- Action.SHORT_DESCRIPTION / ToolTipText

JCheckBox / JRadioButton:
- Action.MNEMONIC_KEY / Mnemonic

JMenu.add(Action a):
- Action.ACCELERATOR_KEY / Accelerator
- Action.MNEMONIC_KEY / Mnemonic
- Action.SHORT_DESCRIPTION / ToolTipText

JPopupMenu.add(Action a):
- Action.ACCELERATOR_KEY / Accelerator
- Action.MNEMONIC_KEY / Mnemonic
- Action.ACTION_COMMAND_KEY / ActionCommand
- Action.SHORT_DESCRIPTION / ToolTipText


Additionally there is another inconsistency concerning JCheckBoxMenuItem and JRadioButtonMenuItem
compared with their non-MenuItem counterparts:
- Action.SMALL_ICON is ignored by JCheckBox/JRadioButton but is honored by the respective MenuItems.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
You can download jUnit testcases at http://www.huxhorn.de/java_bugs/action/action_bugs.zip .
They are contained in the package de.huxhorn.bugs.action.

See the package de.huxhorn.bugs.action.fixed for a different approach. It contains fixes for the
20 failing tests by using the same class to initialize and update the component.

Simply call ant after extraction.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
A workaround/fix can be found in the fixed subpackage.

This bug is a showstopper for my diploma thesis since I change the language of applications  via actions which currently results in partly translated applications with wrong tooltip-text/mnemonic etc.

The fix does not help my thesis directly since using the original swing-classes is has priority.
(Incident Review ID: 246219) 
======================================================================
Comments
EVALUATION WOW! What an incredibly detailed and thorough bug report. Thanks! I downloaded all the test cases and made sure they work:) One point to mention is that in the description this says: - Action.SMALL_ICON is ignored by JCheckBox/JRadioButton but is honored by the respective MenuItems. The rationale for this is that JCheckBox/JRadioButton have an icon, but it's generally the icon for the check/radio and I can't imagine you really want to replace that icon with one from the action. At this point I could only see doing that via another property on the button and/or action. All of this cleanup was done as part of 4626632, refer to it for details.
11-08-2005
EVALUATION Yes, this bug report certainly points out some valid inconsistencies in our Actions implementation. This is definitely something we should resolve. ###@###.### 2004-09-28
28-09-2004