Is TreeModel really as bad as I think?

Question

When I first saw javax.swing.tree.TreeModel, I thought it's quite a lot of work to write all the methods. Then I found the DefaultTreeModel and thought it will be easy to use for file tree via the Adapter pattern. So I started to write the adapter and sort of failed. I need to be able to access the corresponding File given a TreeNode (which is easy since it can be an instance variable), but I need it the other way round as well. This can be solved using a Map, but it ate quite a lot of memory. The switch to WeakHashMap helped.

This worked, but I ran into some strange problems when the tree changed. Additionally, it all was really slow since File.list() got called many times. There are multiple stupid methods like getChildCount(), getChild(Object parent, int index), and getIndexOfChild(Object parent, Object child) and in my naive implementation each call lead to reading a directory.

It all was quite a lot of work and the result was terrible. Sure, my fault, but wasn't it the direct consequence of using a flawed overcomplicated model?

It wouldn't happen, if there was a single method like List getChildren(Object) instead. Maybe I did it all wrong, what's the proper way?

^{Finally, I wrote MyCachingTreeModel implements TreeModel using a per class adapter, which solved it all. But I'm still curios how else it could have been solved.}

Update:

The above may look like a sort of rant, instead of a proper question. So I try it again:

How to implement a TreeModel for the filesystem tree efficiently so that it shows the current state of the directories?

^{My solution doesn't count here, as I circumvented the whole model. Moreover, it caches too much and hardly ever notices any changes.}

Answer 1

(quite late edit:)

How to implement a TreeModel for the filesystem tree efficiently so that it shows the current state of the directories?

I think there isn't a really good way to show a directory tree with JTree so it is always up-to-date. The problem is that the model has to notify its listeners (= the JTree) whenever something important changes, and this is only possible if we regularily recheck the files. So your model at least would need an own Thread. Naturally, it should only check those files whose nodes who are actually displayed - but the model does not really know this (can only guess by the last calls of getValue()).

Maybe one could combine this with the caching problem: Have a cache of directory objects corresponding to the lastly queried nodes, with a "last checked" time. For some time after the first creation they remain valid, we cache the list of child files, but throw them away later. For these same objects which were queried by the tree, we also some time later look again at the file system, and fire the right change events whenever something is not the same as before.

This still relies on lots of heuristics to know which Files have to be checked - maybe instead we should break the layering and let our model simply ask the Tree which nodes are showing, rechecking (and caching) only those.

---

(Old not-really-an-answer:)

When the TreeModel API was created (at the same time as whole Swing), the collection Framework was not there yet. This is also the reason that we need a Vector (instead of List) at multiple places in Swing.

Answer 2

Also: consider the NetBeans Platform and their Node & Explorer APIs

Answer 3

The whole point of having the more complicated API was precisely so that something like File.list() doesn't get called so often. The idea is that for things like counting children which may have to be done many times, you can provide an implementation which does less work than actually getting all the children and then counting them would.

That being said, it doesn't seem like that's really communicated adequately in the API spec, or else you wouldn't have to ask the question. :)