-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
1.4.0, 5.0
-
generic, x86
-
generic, windows_2000
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)
======================================================================
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)
======================================================================
- duplicates
-
JDK-4626632 Various containers for Action throw NPE when PropChgEvent has null newValue
- Resolved