<Swing Dev> [10] RFR JDK-8175968: The javax.swing.filechooser.FileSystemView constructor consumes memory by adding a PropertyChangeListener that is never removed.

[Robin Stevens]

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.sadhukhan at 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.sadhukhan at 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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170707/e0d87552/attachment.html>