Swing-Bäume leicht gemacht

Wer schon einmal Swing-Code unter Nutzung der Baum-Komponente Jtree geschrieben hat, wird wissen, dass es sich bei dem Swing-Baum um ein komplexes Gebilde handelt, das mit Vorsicht zu handhaben ist. Es ist zwar vergleichsweise einfach, einen Baum aus einem statischen Datensatz zu erstellen, doch sobald sich die Daten ändern, kann sich der Jtree-Code rasch in einen undurchdringlichen Dschungel verwandeln. Abhilfe kann da zum Beispiel eine Anwendung der Zen-Programmierung schaffen.

Zunächst einmal ein Blick auf die „klassische“ Vorgehensweise bei der Nutzung von Jtree. Hierbei kommt das DefaultTreeModel zum Einsatz, und es werden DefaultMutableTreeNode-Instanzen erstellt, die die Datenobjekte enthalten. Indem man dann so genannte „Kinder“ zu diesen DefaultMutableTreeNodes hinzufügt beziehungsweise diese entfernt, wird der Baum verändert. Soweit scheint alles ganz einfach. Nach dem Erstellen dieses umfangreichen Baums ist jedoch festzustellen, dass dieser einen erheblichen Speicherbedarf hat. Schlimmer noch: es tritt das gefürchtete Swing-Threading auf, und seltsame Fehlermeldungen scheinen darauf hinzuweisen, dass im Baum ganz andere Dinge geschehen als erwartet.

Im hier angeführten Beispiel galt es, einen Baum aus Tausenden von Online-Diensten stammenden Mitteilungen zu verwalten und diese Mitteilungen in einem Baum durch Threading verknüpften Mitteilungen darzustellen. Das klingt ganz einfach, doch erhält die Mitteilungsdatenbank ihre Mitteilungen von zahlreichen Agent-Prozessen, so dass sie im Grunde dynamisch aufgebaut ist. Da im behandelten Fall bereits drei Baum-Beziehungen in der Mitteilungsdatenbank verwaltet wurden, erschien die Einrichtung eines kompletten doppelten Baums im Speicher überflüssig. Außerdem führte der Versuch der Verwaltung des Ladens der Mitteilungen (die mitunter recht groß sein konnten) dazu, dass sich die GUI-Logik mit der Business-Logik vermischte – ergänzt durch eine Reihe wahllos verteilter Caching-Optimierungen.