toedter.com Board :: View Post :: Better JDateChooser Memory Leak Approach

The JCalendar and HTML sitemap community forum!

Please log in or register.
The date and time is now September 3, 2010, 02:32:17 PM

Kris Kemper
Newbie

I can help.
Posts: 1

Better JDateChooser Memory Leak Approach (August 14, 2008, 04:57:55 PM)

Recently I discovered a memory leak coming from JDateChoosers in my application. It stems from the JDateChooser registering an inner ChangeListener with the MenuSelectionManager in the constructor.

I discovered that there is a cleanup() method, but that is a poor solution - using a WeakReference would allow the Garbage Collector to collect the ChangeListener when the JDateChooser is no longer used.

To be clear, the Memory Leak happens when the references occur like this:
quote:

Main -> JDialog -> JDateChooser -> SomeListener
|
----> ChangeLisener

MenuSelectionManager -> ChangeListener -> JDateChooser -> SomeListener -> JDialog

This kind of circular reference happens when you create anonymous listeners that use code in the containing class.

Anyway, the solution is to create a WeakReference based Proxy for the ChangeListener:
quote:

package com.toedter.calendar;

import java.lang.ref.*;

import javax.swing.event.*;

public class WeakChangeListenerProxy implements ChangeListener {

    public WeakReference reference;

    public WeakChangeListenerProxy(ChangeListener listener) {
        this.reference = new WeakReference(listener);
    }

    public void stateChanged(ChangeEvent e) {
        ChangeListener actualListener = (ChangeListener)reference.get();
        if (actualListener != null) {
            actualListener.stateChanged(e);
        }
    }

}

In JDateChooser, you change the constructor like so:
quote:

// The following idea was originally provided by forum user
// podiatanapraia:
ChangeListener changeListener2 = new ChangeListener() {
// Change listener body
};

changeListener = new WeakChangeListenerProxy(changeListener2);
MenuSelectionManager.defaultManager().addChangeListener(changeListener);

Also, to cleanup the dangling WeakChangeListenerProxy, you add a finalize() method to JDateChooser:
quote:

protected void finalize() throws Throwable {
super.finalize();
MenuSelectionManager.defaultManager().removeChangeListener(changeListener);
}

Kris Kemper

Status: logged off

Order of replies: first reply last :: first reply first

tuler
Newbie

JCalendar is great!
Posts: 3

RE: Better JDateChooser Memory Leak Approach (February 12, 2009, 02:41:21 PM)

Also noted this leak.
Thanks for the fix.

Status: logged off

stever
Newbie

Posts: 2

RE: Better JDateChooser Memory Leak Approach (July 19, 2010, 04:31:11 PM)

This fix has still not been added apparently, in 1.3.3. We have just spent some time chasing memory leaks, finding that one fix is needed in our code to call cleanup(), then also we need this fix to use weak references.
Surely this is very serious if a lot of users are jumping through these same hoops? How many are quietly going elsewhere?

Status: logged off