Memory leak in JSpinner implementation (maybe others?)

Question

Hi,
I am developing an application using Java and Swing, and have run into some problems with memory leaks. After examining the source code and making an example program (provided below), I can only come to the conclusion that there is a bug in the implementation of JSpinner in Sun Java 1.6.0_03.
If one uses a custom model with the JSpinner, it attaches itself as a listener to the model. However, it never removes the listening connection, even if the model is changed. This causes the JSpinner to be kept in memory as long as the model exists, even if all other references to the component have been removed.
An example program is available at http://eddie.dy.fi/~sampo/ModelTest.java . It is a simple swing program that has the JSpinner and two buttons, the first of which writes to stdout the listeners of the original model and the second changes the spinner model to a newly-created model. A sample output is below:
Running on 1.6.0_03 from Sun Microsystems Inc.
Listeners before connecting to JSpinner:
  Model value is 0, 0 listeners connected:
Listeners after connecting to JSpinner:
  Model value is 0, 2 listeners connected:
  1: interface javax.swing.event.ChangeListener
  2: javax.swing.JSpinner$ModelListener@9971ad
Listeners now:
  Model value is 8, 2 listeners connected:
  1: interface javax.swing.event.ChangeListener
  2: javax.swing.JSpinner$ModelListener@9971ad
Changing spinner model.
Listeners now:
  Model value is 8, 2 listeners connected:
  1: interface javax.swing.event.ChangeListener
  2: javax.swing.JSpinner$ModelListener@9971adThis shows that even though the model of the JSpinner has been changed, it still listens to the original model. I haven't looked at other components whether they retain connections to the old models as well.
In my case, I have an adaptor-model which provides a SpinnerModel interface to the actual data. The adaptor is implemented so that it listens to the underlying model only when it itself is being listened to. If the JComponents using the model were to remove the listening connections, it, too, would be automatically garbage-collected. However, since JSpinner does not remove the connections, the adaptor also continues to listen to the underlying model, and neither can be garbage-collected.
All in all, the listener-connections seem to be a very easy place to make memory leaks in Java and especially in Swing. However, as I see it, it would be a simple matter to make everything work automatically with one simple rule: Listen to the models only when necessary.
If a component is hidden (or alternatively has no contact to a parent JFrame or equivalent), it does not need to listen to the model and should remove the connections. When the component is again set visible (or connected to a frame) it can re-add the connections and re-read the current model values just as it does when initializing the component. Similarly, any adaptor-models should listen to the underlying model only when it itself is being listened to.
If the components were implemented in this way, one could simply remove a component from the frame and throw it away, and automatically any listener-connections will be removed and it can be garbage-collected. Similarly any adaptor-models are collected when they are no longer in use.
Changing the API implementation in this way would not require any changes to applications, as the only thing that changes are the listener-connections. Currently used separate connection-removing methods should still work, though they would be unnecessary any more. The API would look exactly the same from the view of an application programmer, only that she would not need to care about remnant listening connections. (As far as I can tell, the current API specification would allow the API to be implemented as described above, but it should of course require it to be implemented in such a way.)
Am I missing something, or is there some valid reason why the API is not implemented like this?
PS. I'm new to these forums, so if there is a better place to post these reports, please tell me. Thanks.

Answer 1

Another cognition: It's the following code, that causes the memory to be accumulated:
obj = m_orb.resolve_initial_references("NameService");
ctx = NamingContextExtHelper.narrow(obj);For the first 4 calls to this code the memory usage of the nameservice is unchanged. From the 5th to the 8th call, it's increased by approx. 10KB per call. And thenceforward (beginning with the 9th call) it's increasing by approx. 10MB.
What's going wrong here?