ConfigurationService.addPropertyChangeListener is currently implemented
using a normal Hashtable. As the Java spec does not guarantee to call the
finalizer of an object, it is sometimes quite difficult or even impossible
to unregister change listeners cleanly.
I'm afraid I don't understand the problem. If the programmer cares
about unregistering a PropertyChangeListener, then shouldn't
ConfigurationService.removePropertyChangeListener be used? Is the
problem specific to Hashtable? Could you please clarify?
If the programmer _knows_ that he is no longer using the notifications this is the right way to go. But often you do not know when you're no longer using a registered notification. Concrete example: A form implemented on top of the ConfigurationForm interface. The form is instantiated through the AdvancedConfigurationPanel. When you navigate away, the reference to the form is thrown away and now collectable through the GC.
Now assume the form registered a change listener. This listener stays in the Hashtable for as long as the whole application lives. There is no way for the ConfigurationForm to know when to call removePropertyListener.
Does anyone have an objection to change the Hashtable to a WeakHashMap?
The WeakHashMap is weak with respect to the key which in the case is
the property name so I'm not sure I see how using it instead of the
Hashtable will be correct. Could you please explain?
Right, my memory lost me. I meant e.g. org.apache.commons.collections.map.ReferenceMap