Looks fine.
Thanks,
Alexander.
On 03/09/2017 07:01, Sergey Bylokhov wrote:
Any volunteers to review?
Thank you =)
On 8/27/17 14:19, Sergey Bylokhov wrote:
Hi,
I would like to propose a new review as a solution which I think
should solve the problem:
Bug:
Any volunteers to review?
Thank you =)
On 8/27/17 14:19, Sergey Bylokhov wrote:
Hi,
I would like to propose a new review as a solution which I think should solve
the problem:
Bug: https://bugs.openjdk.java.net/browse/JDK-8175968
Webrev can be found at:
Hi,
I would like to propose a new review as a solution which I think should solve
the problem:
Bug: https://bugs.openjdk.java.net/browse/JDK-8175968
Webrev can be found at: http://cr.openjdk.java.net/~serb/8175968/webrev.00
- ldubox-coding...@yahoo.co.uk wrote:
> Hi all,
>
> > but imho it
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
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
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
I don't need the credit. Feel free to simply adjust your fix.
Robin
On Wed, Jul 5, 2017 at 7:42 AM, Prasanta Sadhukhan <
prasanta.sadhuk...@oracle.com> wrote:
> Ok. Will you mind preparing a patch for your thought on this fix for us to
> credit you for the fix?
> Regards
> Prasanta
>
> On
Ok. Will you mind preparing a patch for your thought on this fix for us
to credit you for the fix?
Regards
Prasanta
On 7/4/2017 3:32 PM, Robin Stevens wrote:
What I forgot to mention in my previous mail.
The code of that PropertyChangeListener already does an attempt to be
a weak listener,
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.
>
What I forgot to mention in my previous mail.
The code of that PropertyChangeListener already does an attempt to be a
weak listener, but the implementation is wrong.
Because it is an anonymous class, the PropertyChangeListener itself keeps a
hard reference to the FileSystemView instance.
As such,
- There should be no need to create a public dispose method and shift the
responsibility of disposing the listener to the user of the FileSystemView
class.
You can simply convert the PropertyChangeListener to a so-called weak
listener, and keep this PropertyChangeListener an implementation detail
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:
12 matches
Mail list logo
