Posted by bitguru on June 18, 2008
A combination tree/table component has never been a part of Swing, but has been available to Swing programmers for almost as long as Swing itself. The original was written by Philip Milne and Scott Violet before the release of JDK 1.2, when Swing had to be downloaded separately and still used the com.sun.java.swing package name. Read the article and check out the code yourself if you like.
Essentially, it was a clever hack that used a JTree as both a TableCellRenderer (to paint the tree column one cell at a time) and a TableCellEditor (to allow the tree to react to mouse and keyboard events). The code was actually pretty simple, and it did work, but it was limited. After a couple years, some of the limitations had been overcome. A subsequent article provided event handling, and a third supported editing of the tree column. JTreeTable had become usable, but it was still a hack, and it still had rough edges.
Over the years since then, many people have taken JTreeTable and adapted it to their needs. Some of these adaptations have been released for others to download and use. If you look, there are a lot of almost-but-not-quite-compatible versions of JTreeTable out there. Some are commercial, some are free, but they all seem to be based on the Milne/Violet approach. They also all tend to have plenty of pending bugs in their bug-tracking systems.
I’m not familiar with most of the commercial implementations, but of the free ones I’ve seen I like JXTreeTable the best. It’s part of the SwingX project from SwingLabs. It works pretty well and it is actively developed, which means there are regularly-updated releases and that bugs do tend to get fixed, though plenty of bugs remain. A down side is that the implementation is huge. It is built on top of SwingX’s custom JXTable and JXTree components, not directly on Swing’s JTree and JTable.
The interesting news is that there is a new implementation of a Swing tree table component that is not based on the Milne/Violet code. They call it the Outline component. (The name is evidently taken from a tree table component in OSX.) I haven’t had time to take a serious look at it, but it does seem to do a lot of things right. But not quite everything right—at least not yet.
I’m looking forward to keeping an eye on this new implementation. Things I’m hoping for: (1) fewer bug reports than a typical Swing tree table, (2) improved UI consistency, and (3) better and/or simpler handling of fireXxxChanged() events.