JDK-6201473 : JMenuItems created by Action are not garbage collected until Action is collected
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2004-11-30
  • Updated: 2010-04-02
  • Resolved: 2005-08-25
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux localhost.localdomain 2.4.22-1.2115.nptlsmp #1 SMP Wed Oct 29 15:30:09 EST 2003 i686 i686 i386 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
I'm using default Fedora Core 1 installation

A DESCRIPTION OF THE PROBLEM :
There is a serious memory leak in Swing. JMenuItems, JCheckBoxs and JRadioButtons that are created by javax.swing.Action are never garbage collected until the Action is garbage collected. The problem is the following:

Base class javax.swing.AbstractAction has a method
    protected PropertyChangeListener createActionPropertyChangeListener(Action a) {
        return new ButtonActionPropertyChangeListener(this, a);
    }
ButtonActionPropertyChangeListener contains reference to AbstractButton and action itself. The created listener is registered into passed action. But everything is OK here because ButtonActionPropertyChangeListener implements special "weak reference" technique.

The problem appears in subclasses of AbstractButton (JMenuItem, JCheckBox and JRadioButton). These subclasses override createActionPropertyChangeListener method and return anonymous class derived from ButtonActionPropertyChangeListener. That is the problem! because instance of anonymous class (indirectly) contains hard reference on outer class (AbstractButton in our case). Therefore special "weak-reference" technique (implemented in ButtonActionPropertyChangeListener) doesn't work at all. As the result no UI control are collected.

Because it's usual that action can live much longer than UI control we have real memory leak.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
UI controls should be collected
ACTUAL -
Memory leak

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Subclasses of AbstractAction should should not create instances anonimous subclass of ButtonActionPropertyChangeListener. They might create static classes which implement the same memory namagement technique as ButtonActionPropertyChangeListener.

Comments
EVALUATION This was addressed as part of 4626632, closing as a duplicate.
25-08-2005