This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
This is something that has baffled me for ages. Maybe I just can't find it (but I have looked through the API docs in detail). Does anyone know why there is no Tree interface to match List, Map etc. I have to use so many conflicting treelike implementations now, (DOM, JDOM, JNDI, the one from Swing and so on, and so on.) and it seems that the natural place for a single, definitive Tree interface would be in the Collections API. Imagine how fine it would be: java.util.TreeMap implements Map, java.util.Tree javax.swing.JTree extends JComponent implements java.util.Tree org.jdom.Document implements java.util.Tree com.thirdparty.whatever.HugeTree implements java.util.Tree myMethod(java.util.Tree tree) // accept any of the above Sigh... Someone, please, tell me it is there, but I've just not found it ...
But there really isn't anything about JTree that makes it like a TreeMap other than the name. But I checked and none of the classes you are interested in are final so if you really want this functionality why not just subclass each of them adding a Tree interface?
I don't think your missing anything, there is simply no reference implementatation of a tree - weird, uh. Have a look at the link below. It might be useful as it addresses the same issue. http://www.byrden.com/java/Tree/index.shtml Sean
Joined: Jan 07, 1999
there really isn't anything about JTree that makes it like a TreeMap other than the name That's my point, really (although I probably should have named javax.swing.TreeModel, rather than JTree, it's what I was thinking of). Imagine if a there was some sort of standard which provided even basic functionality to traverse up, across and down the tree, and retrieve an Object stored at each node. It doesn't have to be complicated. Extending the Tree interface with a MutableTree interface would be the icing on the cake. It should be easy to make any tree-like data structures implement this sort of interface - they must already be able to do that sort of thing internally. Having a system-supported basic tree data structure would greatly simplify all these tree-like systems. The JNDI API would only need to specify the things about a JNDI repository which are different from a regular tree, and so would JDOM, the swing TreeModel and so on. As for TreeMap, why not provide the ability to treat it as a Tree as well as a Map. Just becaue it doesn't provide that interface now, doesn't mean that it is not a reasonable thing to ask. Suggesting that I (or anyone, really) write my own Tree interface is not really a solution. No one else would probably even know that it exists, let alone implement it in their classes or accept it in their methods. And although superficially attractive, the idea of providing my own wrapper subclasses also fails if the externally provided class doesn't provide an API anything like a tree (and TreeMap doesn't) My main puzzlement is that when the Collections API was designed, they covered so many bases so well, and felt willing to break with tradition to the extent of replacing Enumaration with the broadly similar Iterator. The Collections API competently handles Lists, Sets, Iterators and Maps, but not Trees, and it seems such a glaring omission. Do you remember before we had Map, and couldn't even implement an alternative to Hashtable which could be passed to a method expacting a Hashtable? That's where we are now with trees. Why can't I directly browse a JDOM document or a JNDI repository using a JTree component?