I set the “remove on close” flag on a DefaultMultipleCDockable instance to true by calling setRemoveOnClose(true). I’ve expected that if it is closed, then this instance will be completely removed and at the end it will be garbage collected. After i’ve got OutOfMemory error, i noticed that the DefaultMultipleCDockable instances were not garbage collected.DefaultMultipleCDockable is referenced by DefaultCommonDockable, which again is referenced by some listener (LocatedListenerList??) etc.
Is this a bug? If not, how to remove the instance completely?
best wishes,
ilhami visne
P.S.: I’ve used the Java VisualVM to look at the references.
“remove on close” should remove the Dockable completely, so it is some kind of bug. The connection between DefaultCommonDockable and DefaultMultipleCDockable is intended, but the listeners should be removed.
This morning I’ve tried to create the leak myself but failed, the Dockables always got cleaned up. This does not mean, that there is no leak. Any chance you could provide me your test case/application?
I’ve slightly changed the one of the test program provided in the distribution, DockingFramesTester. The code is below. And i created some screenshots from the Java VisualVM, which may helps.
I found the bug and fixed it, I’ll upload a new version on the next weekend (this fix is already in the repository, if you desperately need it).
The bug happened this way: “SimpleDockAction.KeyForwarder” adds a “DockHierarchyListener” to a Dockable. If the DockController of the Dockable changes, the KeyForwarder updates some internal properties and adds or removes listeners to other modules. If the Dockable gets removed, the KeyForwarder gets destroyed (there is a method “destroy…”). The KeyForwarder also removes its listener from the Dockable if destroyed.
All of that worked very well. But this framework allows to remove a listener while there is an event firing. The listener will receive the event even if it is no longer interested in the event. And in this case, the KeyForwarder received an event and reacted by adding a listener to some module… ergo the garbage collector could not remove the KeyForwarder. And the KeyForwarder contains a reference to a Dockable.
In the test I used there was no SimpleDockAction around, hence the bug did not appear.