I still do not think you need a public dispose method. If you use the weak listener (the correct implementation), the FileSystemView instance can be GC-ed, even when the PropertyChangeListener is still attached to the UIManager.
What you can do is: - Store a reference to the PropertyChangeListener in the FileSystemView class as a field. - Override the finalize method of the FileSystemView class to de-register the PropertyChangeListener from the UIManager. Thanks to the weak listener, the FileSystemView will get GC-ed as the listener no longer keeps a hard reference to it. Not the nicest way to do such cleanup (which should probably happen on the EDT) in a finalizer, but imho it still beats adding an extra method to the API and shifting the burden to the API user. Robin On Thu, Jul 6, 2017 at 3:15 PM, Prasanta Sadhukhan < prasanta.sadhuk...@oracle.com> wrote: > Hi Sergey, > > I tried with the proposed WeakPropertyChangeListener but as far I > understand & tested, it seems also to rely on propertyChange() API to be > called, so the scenario mentioned in the bug will still fail. > I cannot find any other way rather than calling dispose() for the scenario > mentioned there. > > Regards > Prasanta > > On 7/5/2017 4:35 AM, Sergey Bylokhov wrote: > >> Hi, Prasanta. >> Probably it is possible to implement it without users interaction and new >> api? >> >> ----- prasanta.sadhuk...@oracle.com wrote: >> >> Hi All, >>> >>> Please review a fix for a memory leak issue where >>> PropertyChangeListener >>> object added by FileSystemView constructor is never removed. >>> Proposed fix is to add dispose() method to be called by app when they >>> >>> want to remove this resource. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175968 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8175968/webrev.00/ >>> >>> Regards >>> Prasanta >>> >> >
