JDK-4240860 : JToolBar.ActionChangedListener not persistant
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.2.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1999-05-25
  • Updated: 2005-08-25
  • Resolved: 2005-08-25
Related Reports
Duplicate :  
JDK-4626632 - Various containers for Action throw NPE when PropChgEvent has null newValue
Description
Name: vi73552			Date: 05/24/99


When you add an AbstractAction instance to a JToolBar, a PropertyChangeListener is added to the action.  This is so that the JToolBar can listen to the action getting disabled/enabled, the name of the action changing, or the icon associated with the action changing.  The JToolBar reacts to these changes by updating the appearance of the appropriate JToolBar button.  Unfortunately, these PropertyChangeListener's are transient.  After the JToolBar gets serialized/deserialized these operations are no longer executed.  Complicating this problem is that there is no way to re-attach these PropertyChangeListeners without removing and then adding the actions because of access restrictions.
(Review ID: 83419) 
======================================================================
Comments
EVALUATION This has been fixed by 4626632, which resulted in redoing AbstractActionPropertyChangeListener. Serialization now works correctly.
25-08-2005
WORK AROUND Name: vi73552 Date: 05/24/99 temporarily remove the actions during serialization and re-adding the actions after deserialization...akward solution at best ======================================================================
25-09-2004
EVALUATION Name: pzR10082 Date: 02/05/2001 Unfortunately this PropertyChangeListener is essentially non-serializable, because it extends AbstractActionPropertyChangeListener which holds WeakReferences. The other way we could get things work is to re-create it during deserialization. This is, we could call setAction() from readObject() to create and attach this listener as appropriate. Here we meet another problem. Toolbar uses a class inside JToolBar for its buttons. This inner class extends AbstractButton. Suppose we deserialize a button; then AbstractButton class is deserialized first. If AbstractButton.readObject() calls createActionPropertyChangeListener() then this method is taken from the inner class. This inner class has not been derealized yet, in particular, reference to its outer class holds null. We try to call a method defined in the outer class and get an NPE. ###@###.### 2001-02-05 ======================================================================
05-02-2001