Delicate ProgressMonitor/ event handling problem

Question

Hi,
I have a delicate ProgressMonitor / event handling problem.
There exists some solution on similiar problems here in the forums, but no solution to my special problem, hope anybody can help me out.
I have a rather big project, an applet, that I've written a separate JarLoader class that will load specific jar's if the ClassLoader encounter a unloaded class, all ok so far.
But, during loading, I would like to display a ProgressBar. And here is the problem. If my custom ClassLoader intercepts a findClass -request that needs to load the class from a jar from a normal thread, this is no problem, but if the ClassLoader intercepts a findClass that needs loading a jar when inside the EventQueue -thread, this is becomming tricky!
The catch is that an event posted on the EventQueue finally needs a class that needs to be loaded, but I cannot dispatch a thread to do this and end that particular event before the class itself is loaded.
So how do I hold the current EventQueue -event needing a jar -load, Pop up a ProgressBar, then process events in the EventQueue to display the ProgressBar and update repaints in it? then return from the event that now have loaded needed class-files.
I've tried a tip described earlier in the forums by trying to handle events with this code when loading the Jar:
    /** process any waiting events - use during long operations
     * to update UI */
    static public void doEvents() {
        // need to derive from EventQueue otherwise
        // don't have access to protected method dispatchEvent()
        class EvtQueue extends java.awt.EventQueue {
            public void doEvents() {
                Toolkit toolKit = Toolkit.getDefaultToolkit();
                EventQueue evtQueue = toolKit.getSystemEventQueue();
                // loop whilst there are events to process
                while (evtQueue.peekEvent() != null) {
                    try {
                        // if there are then get the event
                        AWTEvent evt = evtQueue.getNextEvent();
                        // and dispatch it
                        super.dispatchEvent(evt);
                    catch (java.lang.InterruptedException e) {
                        // if we get an exception in getNextEvent()
                        // do nothing
        // create an instance of our new class
        EvtQueue evtQueue = new EvtQueue();
        // and call the doEvents method to process the events.
        evtQueue.doEvents();       
    }Then, the loader checks
java.awt.EventQueue.isDispatchThread()to see if its' inside the eventqueue, and runs doEvents after updating the ProgressMonitor with new setProgress and setNote values.
More precise;
The loader is loading the jar like this:
(this is pseudo code, not really usable, but outlines the vital parts)
public void load() {
  monitor = new ProgressMonitor(null, "Loading " + jarName, ""+jarSize + " bytes", 0, jarSize);
  monitor.setMillisToDecideToPopup(0);
  monitor.setMillisToPopup(0);
  // reading jar info code here ...
  JarEntry zip = input.getNextJarEntry();
  for (;zip != null;) {
     // misc file handling here... total = current bytes read
     monitor.setProgress(total);
     monitor.setNote(note);
     if (java.awt.EventQueue.isDispatchThread()) {
        doEvents();
     zip = input.getNextJarEntry();
  monitor.close();
}When debugging doEvents(), there is never any events pending in peekEvents(), even if I tries to put a invokeLater() to run the setProgress on the monitor, why? If it had worked, the doEvents() code would have saved my day...
So, this is where I'm totally stuck...

Answer 1

Just want to describe how I did this using spin from http://spin.sourceforge.net
This example is not pretty, but it can probably help others understanding spin. Cancelling the ProgressMonitor is not implemented, but can easily be done by checking on ProgressMonitor.isCanceled() in
the implementation code.
First, I create a bean for displaying and run a ProgressMonitor:
Spin requires an Interface and an Implementation, but that's just nice programming practice :-)
import java.util.*;
public interface ProgressMonitorBean {
    public void start(); // start spinning
    public void cancel(); // cancel
    public int getProgress(); // get the current progress value 
    public void setProgress(int progress); // set progress value
    public void addObserver(Observer observer); // observer on the progressValue
}Then, I created the implementation:
import java.util.*;
import javax.swing.ProgressMonitor;
import java.awt.*;
public class ProgressMonitorBeanImpl extends Observable implements ProgressMonitorBean {
    private ProgressMonitor monitor;
    private boolean cancelled;
    private int  progress = 0;
    private int  currentprogress = 0;
    public ProgressMonitorBeanImpl(Component parent, Object message, String note, int min, int max) {
        monitor = new ProgressMonitor(parent, message, note, min, max);
        monitor.setMillisToDecideToPopup(0);
        monitor.setMillisToPopup(0);       
    public void cancel() {
        monitor.close();
    public void start() {
        cancelled = false;
        progress = 0;
        currentprogress = 0;
        while (progress < m_cMonitor.getMaximum()) {
            try {
                synchronized (this) {
                    wait(50); // Spinning with 50 ms delay
                if (progress != currentprogress) { // change only when different from previous value
                    setChanged();
                    notifyObservers(new Integer(progress));
                    monitor.setProgress(progress);
                    currentprogress = progress;
            } catch (InterruptedException ex) {
                // ignore
            if (cancelled) {
                break;
    public int getProgress() {
        return progress;
    public void setProgress(int progress) {
        this.progress = progress;
}in my class/jarloader code, something like this is done:
public void load() {
  ProgressMonitorBean monitor = (ProgressMonitorBean)Spin.off(new ProgressMonitorBeanImpl(null, "Loading " + url,"", 0, jarSize));
  Thread t = new Thread() {
    public void run() {
      JarEntry zip = input.getNextJarEntry();
      for (;zip != null;) {
        // misc file handling here... progress = current bytes read
     monitor.setProgress(progress);
  t.start(); // fire off loadin into own thread to do time consuming work
  monitor.start(); // this will spin events on monitor and block until progress = max
  monitor.cancel(); // Just make sure ProgressMonitor is closed
}The beautiful thing here is that Spin is taking care of weither the load() is inside the dispatch thread or not, making the code much simpler and cleaner to understand.
The ProgressMonitorBeanImplementation could been made much nicer and more complete, but I was in a hurry to check if it worked out. And it did! This will be applied on a lot of gui -components that blocks the event-queue in our project, making it much more responsive.
Hope this will help others in similiar situations! Thanks again svenmeier for pointing me to the spin -project.