Swing + threading: the Event Dispatch Thread

Swing has one rule above all others

The single-thread rule: after a Swing component is realized (shown), all code that reads or writes its state must run on the Event Dispatch Thread (EDT) — the one thread Swing uses to dispatch events and paint the screen. Swing is not thread-safe; calling component methods from another thread is a data race that produces intermittent, hard-to-reproduce glitches.

This creates a tension with the Greenhouse project. The controller’s event loop (Module 10: one thread per Event, suspend/resume, synchronized shared state) runs for a long time. If you run it on the EDT, the UI freezes — no repaints, no button clicks — until it finishes. So you face a two-sided constraint:

1. Long work must run OFF the EDT (on a worker thread), or it freezes the GUI.
2. UI updates must run ON the EDT, even when triggered by that worker thread.

Crossing back to the EDT: invokeLater

When a background thread needs to touch the UI (e.g. append a controller status line to the log), it must hand that work to the EDT:

SwingUtilities.invokeLater(() -> log.append("Event fired: LightOn\n"));

invokeLater queues the Runnable onto the EDT’s event queue and returns immediately; the EDT runs it when it next processes events. This is also how you should start a GUI: wrap the window construction in invokeLater from main so even the building of the UI happens on the EDT.

SwingWorker: the structured pattern

SwingWorker<T, V> packages “run long work off the EDT, publish progress, deliver the result on the EDT” into one class:

• doInBackground() runs on a worker thread — put the controller run here. Whatever it returns becomes the result of type T.
• publish(V...) from the worker sends intermediate values; process(List<V>) receives them on the EDT — the safe place to update the log.
• done() runs on the EDT after doInBackground finishes — call get() there to retrieve the result (or surface an exception) and re-enable buttons.

Worked example — run the controller without freezing the panel

runButton.addActionListener(e -> {
    runButton.setEnabled(false);  // on the EDT — safe
    new SwingWorker<Void, String>() {
        protected Void doInBackground() {
            controller.run();           // long work, OFF the EDT
            publish("Controller finished");
            return null;
        }
        protected void process(java.util.List<String> chunks) {
            for (String s : chunks) log.append(s + "\n");  // ON the EDT
        }
        protected void done() {
            runButton.setEnabled(true); // ON the EDT — re-enable
        }
    }.execute();
});

Trace the threads: the click handler runs on the EDT, so setEnabled(false) is safe and instant. Calling .execute() spins up a worker thread to run doInBackground() — controller.run() churns there, never blocking the UI, so the window keeps repainting and the Suspend button stays responsive. When the worker calls publish(...), Swing schedules process(...) back on the EDT, where appending to log is legal. Finally done() runs on the EDT and re-enables Run. Every UI touch is on the EDT; all the slow work is off it.