I think a much better approach would be this:

Instead of allowing direct access to the variable, create a method
that sets the variable.

Within the method, call repaint() for the toolbar (you may also have
to call invalidate() and revalidate() ... I can never quite remember
when you need which).

Or you could set up some sort of Listener interface (PropertyListener
comes to mind), and you could fire an event within the setter method I
mentioned.  The toolbar could be one of the listeners to that event.

I'm having a hard time imagining a situation in which the polling you
describe is the best approach.

   You would create a new class which subclasses the AbstractAction class.
This AbstractAction already provides an implementation for the
setEnabled(boolean) method. You only need to supply an implementation for
the run() method, which is called whenever the action should be executed.

   Then, you take create an instance of the action, and pass it to a
JButton. The JButton will query the Action to find out what its label,
icons, etc. should be ,and render itself appropriately. When you wish to
disable the button, you call setEnabled(false) on the action (not on the
button), and the button will be notified automatically, and grey itself out.

   The advantage of this approach is that you can share the action across
multiple components. For example, you could add your same instance of Action
to a toolbar button, a drop down menu, and a normal click-able button, and
just called setEnabled(false) once on the action, and all three controls
will disable themselves in the appropriate manner.

   - Oliver

Polling is rarely a good idea. A better approach is to encapsulate the
variable. When a method that changes it is invoked, it should also have
the states of the toolbar buttons updated.

If you have more than one thread (the one thread you will have is the
AWT Event Dispatch Thread (EDT), which all repaint and events from the
user are fired on), then you will need to wrap any changes to the Swing
GUI in invokeLater. So:

public class MyClass {
    private final AbstractButton button;
    private boolean myVariable;
    public MyClass(AbstractButton button) {
        this.button = button;
    }
    public synchronized boolean isSet() {
        return myVariable;
    }
    public void set(boolean myVariable) {
        synchronized (this) {
            if (this.myVariable == myVariable) {
                return;
           }
           this.myVariable = myVariable;
        }
        java.awt.EventQueue.invokeLater(new Runnable() {
                public void run() {
                    assert java.awt.EventQueue.isDispatchThread();
                    // NB: isSet is synchronized.
                    button.setEnabled(isSet());
                }
        });
    }
}

(but use better identifier names)

You can go a little more sophisticated. For instance, if a thread
rapidly switches the flag, then loads of events will be queued up making
the program very slow even if it doesn't run out of memory.

Tom Hawtin