Skip to main content

Handle long-running EDT tasks (f.i. TreeModel searching)

Please note these forums are being decommissioned and use the new and improved forums at
4 replies [Last post]
Joined: 2003-06-11

Note: this is a cross-post from SO

copied below, input highly appreciated :-)


Trigger is a recently re-detected SwingX issue ( support deep - that is under collapsed nodes as opposed to visible nodes only, which is the current behaviour - node searching.

"Nichts leichter als das" with all my current exposure to SwingWorker: walk the TreeModel in the background thread and update the ui in process, like shown in a crude snippet below. Fest's EDT checker is happy enough, but then it only checks on repaint (which is nicely happening on the EDT here)

Only ... strictly speaking, that background thread must be the EDT as it is accessing (by reading) the model. So, the questions are:

- how to implement the search thread-correctly?
- or can we live with that risk (heavily documented, of course)

One possibility for a special case solution would be to have a second (cloned or otherwise "same"-made) model for searching and then find the corresponding matches in the "real" model. That doesn't play overly nicely with a general searching support, as that can't know anything about any particular model, that is can't create a clone even if it wanted. Plus it would have to apply all the view sorting/filtering (in future) ...

// a crude worker (match hard-coded and directly coupled to the ui)
public static class SearchWorker extends SwingWorker<Void, File> {
    private Enumeration enumer;
    private JXList list;
    private JXTree tree;

    public SearchWorker(Enumeration enumer, JXList list, JXTree tree) {
        this.enumer = enumer;
        this.list = list;
        this.tree = tree;

    protected Void doInBackground() throws Exception {
        int count = 0;
        while (enumer.hasMoreElements()) {
            File file = (File) enumer.nextElement();
            if (match(file)) {
            if (count > 100){
                count = 0;
        return null;

    protected void process(List<File> chunks) {
        for (File file : chunks) {
            ((DefaultListModel) list.getModel()).addElement(file);
            TreePath path = createPathToRoot(file);

    private TreePath createPathToRoot(File file) {
        boolean result = false;
        List<File> path = new LinkedList<File>();
        while(!result && file != null) {
            result = file.equals(tree.getModel().getRoot());
            path.add(0, file);
            file = file.getParentFile();
        return new TreePath(path.toArray());

    private boolean match(File file) {
        return file.getName().startsWith("c");

// its usage in terms of SwingX test support
public void interactiveDeepSearch() {
    final FileSystemModel files = new FileSystemModel(new File("."));
    final JXTree tree = new JXTree(files);
    tree.setCellRenderer(new DefaultTreeRenderer(IconValues.FILE_ICON, StringValues.FILE_NAME));
    final JXList list = new JXList(new DefaultListModel());
    list.setCellRenderer(new DefaultListRenderer(StringValues.FILE_NAME));
    JXFrame frame = wrapWithScrollingInFrame(tree, "search files");
    frame.add(new JScrollPane(list), BorderLayout.SOUTH);
    Action traverse = new AbstractAction("worker") {
        public void actionPerformed(ActionEvent e) {
            Enumeration fileEnum = new PreorderModelEnumeration(files);
            SwingWorker worker = new SearchWorker(fileEnum, list, tree);
            PropertyChangeListener l = new PropertyChangeListener() {
                public void propertyChange(PropertyChangeEvent evt) {
                    if (evt.getNewValue() == SwingWorker.StateValue.DONE) {
                        //T.imeOut("search end ");
                        ((SwingWorker) evt.getSource()).removePropertyChangeListener(this);
            // T.imeOn("starting search ... ");

    addAction(frame, traverse);

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-06-08


I think in some previous iteration of this discussion that I suggested using a Timer instead of SwingWorker, precisely because the Timer would interact with the model on the EDT.  Each iteration of the Timer would process a specific amount of nodes until all nodes have been processed.  So, for instance, we might go through 10 iterations of the Timer while searching a 1000 nodes.  Not at all sure what the threshold should be for searching (in quantities of nodes or in time), nor am I sure how far we should spread the Timer updates (every 25 ms?).

Another possible solution would be to wrap the model in some sort of EDTcontainer, such that each call to a method is made as a real call to the wrapped model on the EDT.  So the TreeModelEDTWrapper would contain a TreeModel and ensure for instance that getChild is called on the correct thread.  This approach would be fine for a SwingWorker.

While we are supposed to interact with the model on the EDT, I don't know if it is really necessary in this case.  The worst thing that would happen would be a dirty read (obtaining an incorrect value from a node).  That is somewhat problematic in the case of searching, but I'm not sure what the likelihood is that the data will actually change during the search.

What is probably best is a small set of different ways to search.  The last option I present would be the fastest and perfect for clients that know the model is unaltered during the lifetime of the search.  The other two options may be better or worse in some cases.  I have no idea, since these are answers to a thought problem (currently) and not actual testable implementations.

Plus we have other interesting cases: should we prioritize searching from the visible nodes? How do we handle updates to the model?  Cancel the search? Alter the search by searching over previously viewed nodes again?  How do we handle a complete change of the model?  Should these cases affect which algorithm is used?


Joined: 2003-06-11

At the end of the day, it turned out that I asked the wrong question (or right question in a wrong context ;-): the "problem" arose by an assumed solution, the real task to solve is to support a hierarchical search algorithm (right now the AbstractSearchable is heavily skewed on linear search).

Once that will solved, the next question might be how much a framework can do to support concrete hierarchical searchables. Given the variety of custom implementations of TreeModels, that's most probably possible only for the most simple.

Some thoughts that came up in the discussions here and the other forums. In a concrete context, first measure if the traversal is slow: most in-memory models are lightning fast to traverse, nothing needs to be done except using the basic support.

Only if the traversal is the bottleneck (as f.i. in the FileSystemModel implementations of SwingX) additional work is needed:

  • in a truly immutable and unmodifiable TreeModel we might get away with read-only access in a SwingWorker's background thread
  • the unmodifiable precondition is violated in lazy loading/deleting scenarios
  • there might be a natural custom data structure which backs the model, which is effectively kind-of "detached" from the actual model which allows synchronization to that backing model (in both traversal and view model)
  • pass the actual search back to the database
  • use an wrapper on top of a given TreeModel which guarantees to access the underlying model on the EDT
  • "fake" background searching: actually do so in small-enough blocks on the EDT (f.i. in a Timer) so that the user doesn't notice any delay

Whatever the technical option to a slow search, there's the same usability problem to solve: how to present the delay to the end user? And that's an entirely different story, probably even more context/requirement dependent :-)

Joined: 2006-06-08

[quote=kleopatra]Once that will solved, the next question might be how much a framework can do to support concrete hierarchical searchables. Given the variety of custom implementations of TreeModels, that's most probably possible only for the most simple.[/quote]

I would think that we could provide a simple API that we would walk.  Using the Adapter pattern it would be easy for any interested party to provide a facade for their tree model to make it look like ours.


Joined: 2003-06-11

Hi Karl,

yeah, it feels a bit like a recurring discussion (though the last was about expanding, as far as I remember :-)

I like your idea of supporting a set of possibilities, starting with the most simple along the lines of the code as outlined above (that is your third). With experience (developers and users) we might gain more insight into the details/side-effects/requirements of your first two.

BTW, another interesting (as in: requires thought and work) case has been brought up by Walter over at OTN ( : that's lazy loading. In that case at the latest, it's up to the developer to think about something fitting her needs :-)

Thanks for your input, will add a reference to all the threads in the issue tracker