Weak References in Listener Lists
I've found a common source of memory leaks is when objects that add themselves to listener lists forget to remove themselves when they are done.
It would be nice to generalize and say that listener lists should contain weak references, but there are probably valid cases where a listener's only valid reference is through the listener list.
It would be nice to extend the listener pattern so that the listener could specify if they should be referenced weakly, for examplemodel.addChangeListener(this,true)
where true indicates the reference to the listener should be weak.
In some cases like the Model View Controller pattern, it probably makes sense that whenever a view listens to a model it should be weakly referenced. For example, when you construct a JTable and pass the model as a parameter to the constructor, the JTable should always specify a weak reference when it listens to the model.
I think supporting a feature like this in the listener APIs could help reduce the potential for memory leaks and make code a little more maintainable.
> Yes, I thought of that, but the wrapper would not be
> garbage collected. Probably not a big deal though as
> the wrapper would not be very large.
You can remove the wrapper on an event if the referent is null. That's the only thing I can think of at this point. It would be nice if the Reference types could be notified of collections, though.
I have seen this technique used in some places. Personally I think its masking bad behavior. In fact I had to dive into a deep refactor much bigger than intended today because one of my asserts was triggering when a class was being disposed while still listening to other objects. It highlighted issues with my architecture. I'd rather just assert and bigfix.
There was another time that I dabbled in this idea. But it always comes back to objects cleaning up after themselves. Now if its not your code and you cant ensure good behavior, then perhaps there is cause. But I'd keep an assert and report the issue if I saw it trigger.
> There was another time that I dabbled in this idea.
> But it always comes back to objects cleaning up
> after themselves. Now if its not your code and you
> cant ensure good behavior, then perhaps there is
> cause. But I'd keep an assert and report the issue
> if I saw it trigger.
What would fire the assert? The Listener will never be garbage collected while it is listening to something. I assume that you are talking about when the listener is a Swing Object like a JFrame. I don't really like to use gui components as listeners.
If you have to write a clean up method, it kind of defeats the value of having automatic garbage collection to a degree. I like to be able to let my Objects just fall out of scope or just become unreachable when they are no longer needed without having to actively manage their deallocation.
