Taming Swing Threads Part 2: Common Event Queue Pitfalls

Key points from part 1.

Hopefully after reading part 1 you should be feeling pretty comfortable about what the EDT is and how it processes, but just as a reminder, here are the key points from part 1.

• Only the EDT may safely manipulate swing components (it is the uber master swing thread).
• If any other threads are manipulating swing components, they are doing so in an unsafe manner (and bad things will happen).
• The EDT processes events using a simple sequential queue called the Event Queue.

The idea behind part 2 is to explain some of the tricky situations and pitfalls that swing developers often get caught in, as well as hopefully answering some of the questions you have regarding the Event Queue.

Someone jumped the queue!

Every now and then it appears that some swing events are processed in the incorrect order in the Event Queue (and nothing gets my blood boiling like when someone cuts into a queue) resulting in strange behavior. This is best illustrated with a small code snippet. Read the snippet below and think carefully in what order you imagine events will take place.

button.addActionListener(new ActionListener() {

        public void actionPerformed(ActionEvent arg0) {

             repaint();

             doSomething();

        }

});

Most developers would image that repaint() method will result in a painting operation taking place before the doSomething() method call. However this is actually not the case, the call to repaint() will create a new paint event that will be added to the end of the Event Queue. This new paint event will only be processed (dispatched) after the current Action Event has completed. This means that the doSomething() method will be executed before the new Paint Event on the queue is dispatched.

The key point here is that calls to repaint() will create a new paint event that will be added to the end Event Queue and not processed immediately. This means that no events jump the queue (and my blood can remain at its correct temperature).

This queue is going nowhere.

A question I have been asked on numerous occasions is “if all swing interaction can only safely occur on the EDT, why not perform all our tasks on the EDT?”. This is a great question and leads me on to the next common pitfall in swing, problems with long running tasks.

As we discussed earlier, the Event Queue processes all swing interactions: be it painting, mouse clicks or key capture, in a sequential manner. If your code executes quickly, all your screen interactions will be fast and your user interface will feel zippy. However problems arise when long running code is executed by an event.

Common examples of long running tasks include:

• Reading a large file from a drive.
• Performing complex calculations.
• Communicating with data sources or remote machines.

Remember that any operation you perform in an Action Event or other similar events will be completely processed on the EDT, before any other events will be processed These long running tasks will be added to the Event Queue, but will prevent any painting events (or other events) from occurring until the long running task is complete. The result of this is that the GUI becomes unresponsive, as no paint events are being processed.

Below is a simple code snippet that illustrates this problem. The code enters a loop during which it must perform a very long running task.

button.addActionListener(new ActionListener() {

        public void actionPerformed(ActionEvent arg0) {

             for (int counter=0; counter!=3; counter++) {

                        doVeryLongTask();

             }

        }

});

Upon noticing that their GUI is no longer responsive and that painting is not occurring, most new developers try to add a repaint() event in the Action Event to try get the screen to repaint. However we know  that calling repaint() will create a new paint event, but it will only be processed after the Action Event, hence this solution does not work.

button.addActionListener(new ActionListener() {

        public void actionPerformed(ActionEvent arg0) {

             for (int counter=0; counter!=3; counter++) {

                        doVeryLongTask();

                        repaint();

             }

        }

});

The key point to take away from this example is that in order to keep your swing application responsive, you must not perform any long running tasks in the EDT, as the long running event will block the Event Queue and no painting will take place until its finished.

So how on earth do I execute long running tasks?

We have learnt so far that in order to keep you application responsive, you should not perform long running tasks in the EDT that block the Event Queue. This makes total sense, but begs the question “where should long running tasks be executed”. The answer to this question is to perform your processing in another background thread; however this answer opens up an entirely new can of worms.

The following code snippet is the perfect example of what not to do, give it a read and see if you can spot the problem:

button.addActionListener(new ActionListener() {

        public void actionPerformed(ActionEvent arg0) {

                new Thread(new Runnable() {

            public void run() {

                    String answer = calcSomethingComplex();

                    textField.setText(answer);

            }

                }).start();

        }

});

If you cast your mind back to the start of the article you hopefully remembered that swing is a single threaded model and that only the EDT is allowed to interact with swing components. This means that in order to be thread safe, your background task will not be allowed to interact with any swing components.

In the code above, the developer correctly moved the processing of the long running task to a background thread, however the line textField.setText(answer); is not thread safe as it results in a background thread interacting with a swing component. This code violates the golden rule that only the EDT may interact with a swing component.

Help!

So pushing the long running task into a background thread will allow my application to be responsive and zippy, but how on earth do you update the user interface once the long running task is complete?

I’m afraid you will have to read part 3 of the blog to find the answer to this problem.