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

Robin Stevens stevensro at gmail.com
Fri Jul 7 08:34:48 UTC 2017


I am not too familiar with PhantomReferences.

But if I understand the documentation in
http://download.java.net/java/jdk9/docs/api/java/lang/ref/package-summary.html#reachability
correctly, wouldn't you achieve the same result if you use a
PhantomReference in the PropertyChangeListener instead of a WeakReference,
and let the PropertyListener remove itself when the FileSystemView instance
is phantom reachable (which should by doable by passing in that
ReferenceQueue instance in the PhantomReference constructor).

On Fri, Jul 7, 2017 at 10:19 AM, Prasanta Sadhukhan <
prasanta.sadhukhan at oracle.com> wrote:

>
>
> On 7/7/2017 12:51 PM, Robin Stevens wrote:
>
> 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.
>
> finalize() is deprecated from jdk9 and spec says
> http://hg.openjdk.java.net/jdk9/client/jdk/file/
> 80acf577b7d0/src/java.base/share/classes/java/lang/Object.java#l599
>
> Classes whose instances hold non-heap resources should provide a method     * to enable explicit release of those resources,
>
> Regards
> Prasanta
>
> 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/aa4d222d/attachment.html>


More information about the swing-dev mailing list