Thread: 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

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.

Originally Posted by KevinWorkman

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

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.

Originally Posted by KevinWorkman

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...

Originally Posted by KevinWorkman

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.

Originally Posted by KevinWorkman

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.

Originally Posted by KevinWorkman

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

Originally Posted by KevinWorkman

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