Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API
Rather than cram both aspects of the Model-UI pattern into one huge article, I've decided to split up the concept into two, more easily digestible articles. This month, I'll demonstrate how to use the model portion of JTree to capture hierarchical structures; look for my discussion of the UI portion sometime in early '99.
We'll begin with a brief look at the MVC architectural pattern and examine how it is integrated into Swing. Then, we'll move into a detailed discussion of the Swing tree package and its interfaces. Along the way, we'll examine listeners and various strategies for using the tree package. Finally, we'll bring our discussion to a close with a look at a simple program that demonstrates Swing's tree capabilities in action.
We've got a lot to cover, so let's get started!
Swing's Model-UI architecture is a variation of the MVC (Model-View-Controller) pattern (see Resources). The MVC pattern, first introduced in Smalltalk-80, was designed to reduce the programming effort required to build systems that made use of multiple, synchronized presentations of the same data. The MVC consists of three distinct parts:
The MVC pattern prompts the following software qualities, which make it such a novel idea:
Loose coupling -- The model publishes only an interface for notification. Each view implements this interface, but the model does not know, nor, care about the view beyond this interface.
Pluggabilty -- We can add new views easily, without changing the model.
The MVC design pattern is typically used for constructing user interfaces that may present multiple views of the same data.
The design pattern is extremely important because it completely de-couples data display from data representation. This means
that the user interface of an application can be completely changed -- even dynamically, under direction of the user -- without need for any change to the underlying data subsystem
of the application. As long as you can implement the model (TreeModel, more on this later), your view does not have to change.
All Swing data-representation components are implemented with this design pattern in mind, so all Swing applications will inherently benefit from this immense design flexibility.
JTree component architecture
The following figure illustrates the Model and UI (View-Controller) portions of the JTree component.

Swing's JTree component architecture
JTree, the portion that manages the rendering of the tree data, is defined by the TreeUI interface.TreeModel object. As you'll see later, the data can be any arbitrary hierarchy of information; it need not even all be held in memory
at once, it can be simply fetched as needed.TreeSelectionModel; this allows Swing to manage different selection strategies (continuous selection, discontinuous selection, for example)
We'll now take a more detailed look at the classes that are involved in Swing's tree component:
Most of JTree's model entities are part of the com.sun.java.swing.tree package. Below is a simple class diagram that describes the main
entities and the relationships between them. (Note that there are more classes in the package, but I omitted those that aren't
directly related to the model part of JTree.)

Main entities of the Swing tree package
In keeping with good design practice, the tree package is divided into abstraction and implementation layers. In fact, the tree package provides several degrees of abstraction. At the highest level are the TreeModel, TreeSelectionModel, and TreePath interfaces and classes, which simply describe a data/selection model of Objects. Practical implementations of these interfaces are provided by DefaultTreeModel and DefaultTreeSelectionModel, which describe a tree consisting of TreeNode and MutableTreeNode objects. Finally, a practical implementation of these node interfaces is provided by DefaultMutableTreeNode. These different levels of abstraction are described in detail below.
Interfaces denote the contract that a given component must fulfill in order to participate in a particular collaboration. The tree package defines one main
data model contract -- the TreeModel interface, and two node interfaces, TreeNode and MutableTreeNode -- that you use when working with the default tree model implementation. Data-related communications are performed with TreeModelEvent and TreeModelListener.
Let's examine these contracts (interfaces) in more detail.
The TreeModel contract
The TreeModel interface defines the contract that a general tree-like hierarchical collection for a hierarchical data must fulfill. The
interface should be implemented by any class that holds hierarchical data (the File system, for example) and wishes to use
the JTree component as its GUI. In order to keep the contract as general as possible, all of the TreeModel methods accept and return an Object class, instead of a more constrained type, which allows you to implement the interface for constructing your own hierarchical
data structures of arbitrary datatypes.
Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq
![]()
Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq