Welcome to the Java Programming Forums


The professional, friendly Java community. 21,500 members and growing!


The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.


>> REGISTER NOW TO START POSTING


Members have full access to the forums. Advertisements are removed for registered users.

Results 1 to 12 of 12

Thread: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

  1. #1
    Member
    Join Date
    Oct 2012
    Posts
    38
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Default Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    I'm hoping this is a simple question with an easy answer. I have a fairly large JTree that I need to remove a node from, but that node may have children and those children may have children of their own. I know that the "removeNodeFromParent" method of the JTree's registered DefaultTreeModel instance is the right way to take out a single node, but I don't know what happens to the removed node's children. They don't show up in the JTree any more, that's easy enough to test, but... Do they linger around in memory somewhere? Will the Garbage Collector collect them eventually?

    My reasoning here is pretty basic. If removeNodeFromParent also cleans up the removed node's lineage, then I don't need to mess with my programme any more. If it doesn't, then I'll need to add in recursion to find all the leaves, delete them, then work back towards the node-to-be-removed. And I'm hoping I won't have to


  2. #2
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,424
    My Mood
    Hungover
    Thanks
    144
    Thanked 636 Times in 540 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    You could try creating a program that constantly adds and removes nodes using that method and check what the memory does over time. Or you could dig through the source, which is including with the JDK.
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  3. #3
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    You dont need to care about things like that. The garbage collector will find everything that is not using a System resource. (Threads, IO-Streams, etc)
    Dont try to over-optimize your code before you actually run into a problem. And when there is a memory problem with your program use a profiler to find out where it is.

  4. #4
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,424
    My Mood
    Hungover
    Thanks
    144
    Thanked 636 Times in 540 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    Quote Originally Posted by Cornix View Post
    You dont need to care about things like that. The garbage collector will find everything that is not using a System resource. (Threads, IO-Streams, etc)
    This is a bit of an oversimplification. Sure, the garbage collector will take care of eligible memory, but he's asking whether that memory is eligible. It's actually not immediately obvious whether the model (or OP's code) keeps track of those nodes somewhere. I would assume it doesn't, but it's not as simple as "you don't need to care about it".

    Quote Originally Posted by Cornix View Post
    Dont try to over-optimize your code before you actually run into a problem. And when there is a memory problem with your program use a profiler to find out where it is.
    I agree with this part though.
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  5. #5
    Member
    Join Date
    Oct 2012
    Posts
    38
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    Quote Originally Posted by KevinWorkman View Post
    This is a bit of an oversimplification. Sure, the garbage collector will take care of eligible memory, but he's asking whether that memory is eligible. It's actually not immediately obvious whether the model (or OP's code) keeps track of those nodes somewhere. I would assume it doesn't, but it's not as simple as "you don't need to care about it".
    Right, that's what I was asking. I know the garbage collector will, um... "Collect" objects with no references pointing to them, but I don't know if that's the case with the children of a removed JTree node. I surmise that it is, but I don't know this for a fact. I was hoping for an easy answer, but I accept that there isn't one. Still, thank you kindly for the help

  6. #6
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    It will not only collect objects with no reference pointing to them. It can also collect objects that are referenced.
    How exactly the gc works is not that important, but it might be something like a reference graph. All objects are nodes in this graph, and an edge between 2 objects means, that a reference exists between these two objects.
    The gc will collect all sub-graphs that are not reachable from the main method in some way or another.

  7. #7
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,424
    My Mood
    Hungover
    Thanks
    144
    Thanked 636 Times in 540 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    Quote Originally Posted by Cornix View Post
    It will not only collect objects with no reference pointing to them. It can also collect objects that are referenced.
    Can you give us an example? The only one I can think of is a WeakReference, but that's a pretty special case.

    Quote Originally Posted by Cornix View Post
    The gc will collect all sub-graphs that are not reachable from the main method in some way or another.
    The OP's question is whether those sub-graphs are reachable. (Although, a reference doesn't have to be reachable from the main method to be considered reachable.)
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  8. #8
    Member
    Join Date
    Oct 2012
    Posts
    38
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    Quote Originally Posted by KevinWorkman View Post
    The OP's question is whether those sub-graphs are reachable. (Although, a reference doesn't have to be reachable from the main method to be considered reachable.)
    Right, that. I am, unfortunately, not entirely clear on what is considered reachable and what isn't. Can two objects referencing each other but each without a reference exposed to ME considered to be reachable? I can see items considered unrechable if they're not exposed to the Main method, but how does that work with multi-threading? Swing is, after all, pretty heavily multi-threaded. I've actually had issues like that, where windows won't close with the main programme because I'd failed to associate them with the main JFrame. Been there, done that

    I suppose I can just chance it. What I'm talking about is bound a button, so it's not something that'll happen thousands of times per second. At worst, I can afford to have a few errant objects floating around, I think.

    Again, thank you for the information. I'm really uneducated when it comes to the inner-inner guts of Java...

  9. #9
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,424
    My Mood
    Hungover
    Thanks
    144
    Thanked 636 Times in 540 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    Quote Originally Posted by Fazan View Post
    Can two objects referencing each other but each without a reference exposed to ME considered to be reachable?
    That situation is, funnily enough, called an "island of isolation", and you can google that for more info. Basically those objects are unreachable and are eligible for garbage collection.

    Quote Originally Posted by Fazan View Post
    I can see items considered unrechable if they're not exposed to the Main method, but how does that work with multi-threading?
    Object reachability has nothing to do with the main thread or the main method.

    Quote Originally Posted by Fazan View Post
    I suppose I can just chance it. What I'm talking about is bound a button, so it's not something that'll happen thousands of times per second. At worst, I can afford to have a few errant objects floating around, I think.
    I'm 90% sure that the objects are no longer reachable and will become eligible for garbage collection. The only reason I'm not saying I'm 100% sure is the off chance that the children of removed nodes are added to the parent of the removed nodes (this seems unlikely but not impossible, I haven't read the documentation), or in case you have code that's keeping a reference to them around (say, an ArrayList of the nodes you've created). If neither of those cases is true, then they're unreachable.
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  10. #10
    Senior Member
    Join Date
    Jul 2013
    Location
    Europe
    Posts
    666
    Thanks
    0
    Thanked 121 Times in 105 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    Quote Originally Posted by KevinWorkman View Post
    Can you give us an example? The only one I can think of is a WeakReference, but that's a pretty special case.
    I am talking about things like this:
    public class GCExample {
     
    	public static void main(String[] args) {
    		A a1 = new A();
    		A a2 = new A();
     
    		a1.myA = a2;
    		a2.myA = a1;
     
    		a1 = null;
    		a2 = null;
    	}
     
    	public static class A {
    		public A myA;
    	}
     
    }
    The objects a1 and a2 are both referencing each other. Both are being referenced, but both are also eligible for garbage collection at the end of the main method.

    Quote Originally Posted by KevinWorkman View Post
    The OP's question is whether those sub-graphs are reachable. (Although, a reference doesn't have to be reachable from the main method to be considered reachable.)
    Yes, not necessarily from the main method. I was just trying to simplify things. After all, you can never tell for sure whether the gc actually creates such a graph or not. There might be any kind of black voodoo magic involved in the background. The point is, we should not think about it too much and just take it that the gc will do the correct thing.

  11. #11
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,424
    My Mood
    Hungover
    Thanks
    144
    Thanked 636 Times in 540 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    Quote Originally Posted by Cornix View Post
    The objects a1 and a2 are both referencing each other. Both are being referenced, but both are also eligible for garbage collection at the end of the main method.
    Like I said, that's called an island of isolation.

    Quote Originally Posted by Cornix View Post
    Yes, not necessarily from the main method. I was just trying to simplify things. After all, you can never tell for sure whether the gc actually creates such a graph or not. There might be any kind of black voodoo magic involved in the background. The point is, we should not think about it too much and just take it that the gc will do the correct thing.
    There is no black voodoo magic, and you can read all about how the garbage collector works. I agree that you shouldn't really worry about implementation details unless you have to, but the OP's question was never about how the garbage collector worked- it was how the DefaultTreeModel worked. He understands that unreferenced variables are eligible for garbage collection. He's asking whether the DefaultTreeModel actually unreferences the particular nodes in question. The answer is probably, but he should check the documentation and the source, or create a little test program, to really answer it.
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  12. #12
    Member
    Join Date
    Oct 2012
    Posts
    38
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Default Re: Dooes the "removeNodeFromParent" method from DefaultTreeModel remove grandchildren?

    Quote Originally Posted by KevinWorkman View Post
    That situation is, funnily enough, called an "island of isolation", and you can google that for more info. Basically those objects are unreachable and are eligible for garbage collection.
    Huh... I did not know that. Thank you kindly, I'll go read up on that

    Quote Originally Posted by KevinWorkman View Post
    I'm 90% sure that the objects are no longer reachable and will become eligible for garbage collection. The only reason I'm not saying I'm 100% sure is the off chance that the children of removed nodes are added to the parent of the removed nodes (this seems unlikely but not impossible, I haven't read the documentation), or in case you have code that's keeping a reference to them around (say, an ArrayList of the nodes you've created). If neither of those cases is true, then they're unreachable.
    If that's the only case of concern, then I don't suspect that's the case. If the children of a removed node are added to the parent of the removed node, then they'd show up in the graphics representation when calling treeModel.nodeHasChanged(removedNode). I had this into the programme prior to figuring out how to do node addition and subtraction using an instance of DefaultTreeModel rather than by using the DefaultTreeNode "add" and "remove" methods. When I tried it, the nodes did not show up.

    Now, I'm presuming that the nodes will show up in the graphical representation as that's what I understand the nodeHasChanged method to do - update the node to show changes to the JTree after it. If the nodes were still attached to each other, they should show up. If they don't show up, then that must mean they're not attached to any node that traces back to the root. And since I THINK JTree nodes are only ever attached to each other and not to the JTree (aside from the Root), then that means they should be unreferenced, right?

    Sorry that what I say is so full of conjecture, but it does make me sort of happy with how I have things set up

Similar Threads

  1. Replies: 4
    Last Post: July 18th, 2014, 02:04 AM
  2. Replies: 1
    Last Post: July 16th, 2014, 04:16 AM
  3. Replies: 2
    Last Post: May 22nd, 2014, 01:17 PM
  4. Replies: 2
    Last Post: June 22nd, 2013, 10:30 AM
  5. Replies: 1
    Last Post: March 15th, 2010, 10:03 PM

Tags for this Thread