Re: Memory leaks in TreeView, ListView, TableView

>> Right. Arguably, pivot.util.ListenerList could be using >> WeakReferences, which would eliminate this problem (treeData would >> never develop a string reference back to treeView). However, it would >> also arguably hurt the performance of listener lists, which would be >> unfortunate. That's

Re: Memory leaks in TreeView, ListView, TableView

Hi to all, > Right.  Arguably, pivot.util.ListenerList could be using > WeakReferences, which would eliminate this problem (treeData would > never develop a string reference back to treeView).  However, it would > also arguably hurt the performance of listener lists, which would be > unfortunate.  

Re: Memory leaks in TreeView, ListView, TableView

>What do you think will happen to the inner class I created to handle the >event? >That right, it will get GC'ed, but not before working for somewhere >between a few seconds and a few minutes (depending on memory pressure) >and thus completely confusing the poor programmer. Yup. I ran into this ex

Re: Memory leaks in TreeView, ListView, TableView

Todd Volkert wrote: > Right. Arguably, pivot.util.ListenerList could be using > WeakReferences, which would eliminate this problem (treeData would > never develop a string reference back to treeView). However, it would > also arguably hurt the performance of listener lists, which would be > unfor

Re: Memory leaks in TreeView, ListView, TableView

>That's assuming that weak references are slower than >strong references, which I thought I read somewhere... They are slower because they need to do a hashtable lookup instead of a pointer dereference. >Agreed. Though this discussion has piqued my interest about renewed >discussions in Listene

Re: Memory leaks in TreeView, ListView, TableView

> WeakReferences are not a solution, because the application developer > might not keep a reference to treeData, which means the TreeView would > mysteriously lose it's connection to the data object when GC next runs. Right. Arguably, pivot.util.ListenerList could be using WeakReferences, which w

Re: Memory leaks in TreeView, ListView, TableView

Christopher Brind wrote: > Since treeData is private, why not use a WeakReference? > http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ref/WeakReference.html > > > WeakReferences are not a solution, because the application developer might not keep a reference to treeData, which means the TreeVie

Re: Memory leaks in TreeView, ListView, TableView

Since treeData is private, why not use a WeakReference? http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ref/WeakReference.html Cheers, Chris 2009/3/13 Greg Brown > I think such a scenario may be developer error. We can't reliably detect > when a component is or is not part of the component

Re: Memory leaks in TreeView, ListView, TableView

I think such a scenario may be developer error. We can't reliably detect when a component is or is not part of the component hierarchy: a component can tell when it has been added or removed, but not when an ancestor has been added or removed. On the other hand, an application developer kno

Memory leaks in TreeView, ListView, TableView

Scenario: 1) 'treeView' is created with 'treeData' and added to the component hierarchy. 2) 'treeView' adds itself as a ListListener on 'treeData', causing 'treeData' to maintain a reference to 'treeView' 3) 'treeView' is removed from the component hierarchy, but the user still needs a reference

Memory leaks in TreeView, ListView, TableView

Scenario: 1) 'treeView' is created with 'treeData' and added to the component hierarchy. 2) 'treeView' adds itself as a ListListener on 'treeData', causing 'treeData' to maintain a reference to 'treeView' 3) 'treeView' is removed from the component hierarchy, but the user still needs a reference