Re: Could this be done better
On 11/24/2014 6:16 AM, Cecil Westerhof wrote:
I have mostly programmed back-ends. But I now want also to do some
front-end programming.
I wrote the following simple program. It does nothing useful, it just
displays a description in different colours with the colour appended
to the description.
I was just wondering if this could be done better. Especially
???updateColour???. First I did not removed the text, but then I could see
the colour changing before the text was changed. This way I find more
pleasing and I do not notice that the text disappears.
One rather important point you've overlooked: Swing is (mostly)
not thread-safe. Swing methods should only be invoked on the Event
Dispatching Thread (EDT), except for the very few methods that are
specifically documented as safe for use from other threads.
Your program violates this rule in two ways:
- The ColourCycling constructor builds a JFrame and invokes
assorted methods on it, and also builds a JLabel -- but the
constructor is called from a thread that is not the EDT.
- The updateColour() method manipulates the JLabel, but is
called from some random thread created by Timer -- again, not
the EDT.
The first problem is one of those "it almost always works
right" issues, the kind that will not bite you -- until the demo
for the Big Boss and the Big Customer. (Sun themselves did not
at first realize it was a problem, and many early Swing examples
illustrated exactly the same mistake you've made.) Fortunately,
it's easy to fix: Use the SwingUtilities.invokeLater() method to
run the ColourCycling constructor on the EDT instead of on the
initial thread. (For clarity's sake, I'd suggest moving the
JLabel construction inside the ColourCycling constructor, too:
That's where the byte code winds up, but let's be explicit, OK?)
The second problem is (most likely) the cause of the strange
display glitches you refer to: You're updating the display from
a non-EDT thread, and the EDT doesn't "know" right away that things
have changed. There are at least two ways to cure it:
- Inside the TimerTask, use SwingUtilities.invokeLater() to
launch a Runnable that calls updateColour(), so that the call runs
on the EDT instead of on the Timer's thread.
- Use javax.swing.Timer instead of java.util.Timer. The
mechanics are a bit different -- you write an ActionListener
instead of subclassing TimerTask -- but the action listener
automatically runs on the EDT, where it's safe to manipulate
your GUI.
Recommended reading:
http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM