Applets - init(), EDT and threads

Question

Java is not my mother tongue and I've been fighting with this problem for a little while.

Basically, I am finding a behavioural difference between calling method switchApplets() directly from init(), and calling it from within a new thread spawned by init().

The consequence of calling it from inside the new thread is that the new applet whitescreens -- until/unless the user resizes or minimizes their browser. If called at the end of init(), the new UI renders immediately without any input from the user. But that's not an option because it doesn't wait for the thread to finish its prep work.

Trimmed-down code:

public class PreLoader extends Applet implements AppletStub {

static JProgressBar pBar = null;
static JLabel message;

public void switchApplets() {
    try {
        Class main_class = Class.forName("MainClass");
        Applet main_applet = (Applet)main_class.newInstance();
        removeAll();
        setSize(0,0);
        setLayout(new GridLayout(1,0));
        add(main_applet);
        main_applet.init();
        main_applet.start();
        main_applet.setStub(this);
    }
    catch (Exception e) {
    }
}

public void init() {

    pBar = new JProgressBar(0, 100);
    pBar.setValue(0);
    pBar.setStringPainted(true);

    message = new JLabel("Beginning work!");

    add(message);
    add(pBar);

    FlowLayout flow = new FlowLayout();

    setLayout(flow);

    Thread t = new Thread ( new Runnable () {
        public void run ()
        {
            longRunningFunction1();
            longRunningFunction2();
            message.setText("Work complete! Stand by..");
            switchApplets(); //does NOT work as intended from here
            return;
        }
    } );
    t.start();
    //switchApplets(); //works as intended if called HERE
}

public void longRunningFunction1() {
    //perform some tasks, advance progress bar
}

public void longRunningFunction2() {
    //perform some tasks, advance progress bar
}

public void start() {
    return;
}

public void appletResize(int width, int height) {
    return;
}

}

I tried making init() wait for the thread to finish so that I could call switchApplets() from there, but that only blocked the EDT and prevented the UI from updating. Also tried playing with SwingUtilities' invokeLater/invokeAndWait, but even though switchApplets() gets run on the EDT, it seems that it MUST be called directly from init() (or at least the thread init is running on) to have the desired effect.

Why does calling switchApplets() from within a new thread result in a slightly different (and unwanted) UI behaviour?

Answer 1

The consequence of calling it from inside the new thread is that the new applet whitescreens -- until/unless the user resizes or minimizes their browser.

It's likely a deadlock caused by trying to do UI code on the wrong thread.

I tried making init() wait for the thread to finish so that I could call switchApplets() from there, but that only blocked the EDT and prevented the UI from updating.

You're on the right track. You need to call switchApplets() only from the EDT, and only after the work is done on the other thread.

Are you sure you tried using invokeLater() or invokeAndWait() from within the spawned thread after the long running functions were done? It's been a long while since I did applets but I'm not aware of any applet-specific reason why it wouldn't work, and it would work in any other case. I.e.,

public void run()
{
    longRunningFunction1();
    longRunningFunction2();
    SwingUtilities.invokeLater(new Runnable() {
        public void run() {
            message.setText("Work complete! Stand by..");
            switchApplets();
        }
    });
}

However, the most proper way to do this is with a SwingWorker rather than a manually created thread. SwingWorker (which is not nearly as well-known as it should be) is designed exactly for the goal of performing background tasks on a separate thread while still being able to update the GUI with progress updates and the results. E.g.,

new SwingWorker<Void,Void>() {
    @Override
    protected Void doInBackground() { // is called on a background thread
        longRunningFunction1();
        longRunningFunction2();
        return null;
    }

    @Override
    protected void done() { // is called on the Swing thread
        message.setText("Work complete! Stand by..");
        switchApplets();
    }
}.execute();

The Void stuff is because SwingWorker is also capable of returning results and sending intermediate progress updates, but this example doesn't use those features.

You indicated that your long running functions are also updating a progress bar. That's another thing that should happen only on the Swing thread. In practice you can often get away without it, but it's dodgy. Your progress updates can use one of the SwingUtilities.invoke methods, or the mechanisms of SwingWorker; either should work. (SwingWorker itself provides two different ways to do it: Call addPropertyChangeListener (Swing thread) and setProgress (background thread), or call publish (background thread) and override process (Swing thread).)

Also, a small suggestion: if it's inconvenient to deal with a checked exception (or impossible to usefully do so), rather than catching and ignoring it, you should at least catch & rethrow it as an unchecked exception:

catch (Exception e) {
    throw new RuntimeException(e);
}

That way, the stacktrace and error message of any exception will not be lost.