Re: can JTree's have multiple roots and models ?

Oliver Wong wrote:
"Thomas Hawtin" <usenet@xxxxxxxxxxxxxxxxx> wrote in message news:43626ccb$0$49783$ed2e19e4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Oliver Wong wrote:

"Thomas Hawtin" <usenet@xxxxxxxxxxxxxxxxx> wrote in message news:43617af8$0$6529$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

When layering models like this, you need to be careful with listeners. You should make sure when the model nearest the component has no listeners attached to it, it has no listeners attached to the underlying model(s). If you don't, you might find yourself with a small (or otherwise) memory leak.


I'm guessing the easy fix for this would be to have your "super TreeModel" register listeners on all of its sub TreeModels right away, and then never fiddle with the listeners from there on. Then, the super TreeModel receives an event from one of its sub TreeModels, it just forwards these events to its own registered listeners.

Would there be any problems with this implementation?

The problem is you have (strong) references set up as below (the upper arrows represent the references via listeners typically implemented as inner classes of some description).

             <------                 <------
       JTree         Composite model         Underlying model
             ------>                 ------>


I don't understand what you mean by inner classes. 

http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.3

Listeners are implemented as inner classes the vast majority of the time. Often anonymous inner classes.

For now I'm assuming this has something to do with Sun's implementation of listeners that you know about and I don't, because the way I understand it, the subscriber does indeed initially need a reference to the observed object to subscribe to it, but it can then forget about that reference. The observed object, simply needs a list of references to all items subscribing to it; when no one is subscribing to it, that list is empty (i.e. it doesn't have references to any other object).

In the case of listening to input events, that's true. If I have an action listener, there is no further information necessary to perform the action. In some circumstances you might want to reduce the class count and use the event source to distinguish between a series of actions.

In the case of listeners to state change events, there isn't enough information to do anything useful. If you want to repaint a tree, you need to go back to the tree model and get values for each of the showing nodes.

You also need a reference to the observed object in order to remove the listeners.

(I'm also not sure I understand the significance and distinction between the upper and lower arrows).

The leftward (upper) arrows represent an indirect strong reference, via a listener, from the observed/publisher/event source to the interested object. The rightward (lower) arrows represent the direct strong reference from the interested object to the observed/publisher/event source.

The JTree and composite model are all about a single display. Suppose the underlying model is longer lived. Removing the composite model from the JTree should free up all the required memory, but you end up with:

                                     <------
       JTree         Composite model         Underlying model
                                     ------>


The composite model (and anything it refers to) is not collectible.


I thought Sun's garbage collection algorithm had something to do with whether the objects were reachable from live code. Assuming the composite model and the underlying model don't have any threads looping in one of their methods, once the thread -- the one that told the JTree to unsubscribe from the composite model -- leaves the scope of the JTree, the composite model and underlying model will no longer be reachable, and thus be collectible.

Often the underlying model will have a longer lifetime. If this is the case, then the observing model will still be strongly reachable, after it has server its useful lifetime. Memory leak.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
.

Relevant Pages

  • Re: can JTrees have multiple roots and models ?
    ... should make sure when the model nearest the component has no listeners attached to it, it has no listeners attached to the underlying model. ... I'm guessing the easy fix for this would be to have your "super TreeModel" register listeners on all of its sub TreeModels right away, and then never fiddle with the listeners from there on. ... The JTree and composite model are all about a single display. ... Suppose the underlying model is longer lived. ...
    (comp.lang.java.gui)
  • Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
    ... docNode.addEventListener('DOMContentLoaded', documentReadyListener, ... I don't really follow and these circular references make my head hurt. ... listeners shares a closure with the wrapped listener functions, ... I don't have any unload cleanup for DOM2 as the only circular memory ...
    (comp.lang.javascript)
  • Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
    ... references involving DOM elements in the library's closure. ... unload cleanup as strictly a safeguard for applications that create ... I use detachEvent on all the listeners in the IE branch. ...
    (comp.lang.javascript)
  • Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
    ... handler, options) { ... If your array that holds references to the elements with attached ... I use detachEvent on all the listeners in the IE branch. ...
    (comp.lang.javascript)
  • Re: repopulating my select
    ... is this a "memory leak" ... It's worth noting that listeners may or may ... not be cloned depending on how they were attached and which browser is ... This method doesn't break circular references involving ...
    (comp.lang.javascript)