Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > danger JLabel.settext() in another thread

Reply
Thread Tools

danger JLabel.settext() in another thread

 
 
Yamin
Guest
Posts: n/a
 
      07-21-2004
Hey all,

I was wondering how dangerous calling JLabel.setText from a thread
other than the event dispatching thread. I know its illegal, but its
in there. I'm looking at some code which does this, but so far it has
not caused any problems and its passed testing.

Basically, it's just a thread that updates the elapsed time. Don't
ask me why its in its own thread...I didn't write it.


Yamin
 
Reply With Quote
 
 
 
 
Remi Bastide
Guest
Posts: n/a
 
      07-21-2004
What about :

SwingUtilities.invokeLater(
new Runnable() {
public void run() {
myLabel.setText("hello");
}
}
}

?

http://www.velocityreviews.com/forums/(E-Mail Removed) (Yamin) wrote:

>Hey all,
>
>I was wondering how dangerous calling JLabel.setText from a thread
>other than the event dispatching thread. I know its illegal, but its
>in there. I'm looking at some code which does this, but so far it has
>not caused any problems and its passed testing.
>
>Basically, it's just a thread that updates the elapsed time. Don't
>ask me why its in its own thread...I didn't write it.
>
>
>Yamin


 
Reply With Quote
 
 
 
 
Matt Humphrey
Guest
Posts: n/a
 
      07-21-2004

"Yamin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> Hey all,
>
> I was wondering how dangerous calling JLabel.setText from a thread
> other than the event dispatching thread. I know its illegal, but its
> in there. I'm looking at some code which does this, but so far it has
> not caused any problems and its passed testing.
>
> Basically, it's just a thread that updates the elapsed time. Don't
> ask me why its in its own thread...I didn't write it.


It's illegal because it will eventually conflict with whatever Swing is
doing. Although setting text seems simple, Swing is accessing font sizes,
graphics contexts and so forth. Having the underlying string (reference)
change may cause any number of problems. In my experience with this
particular case (which was a while ago), I usually end up with the label
truncated, not resizing and possibly with unexplained crashes. Because the
symptoms depend strongly on the timing within the virtual machine, and other
platform-dependent things, you may not see any problems until your customer
runs the program on a different machine.

Cheers,

Matt Humphrey (E-Mail Removed) http://www.iviz.com/


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-21-2004
On 21 Jul 2004 08:13:34 -0700, (E-Mail Removed) (Yamin) wrote or
quoted :

>I was wondering how dangerous calling JLabel.setText from a thread
>other than the event dispatching thread. I know its illegal, but its
>in there. I'm looking at some code which does this, but so far it has
>not caused any problems and its passed testing.



Unlike the AWT, Swing is not threadsafe. You can't directly meddle
with Swing components, or their backing data models from a second
thread. The contract is, if you want to do anything to a Swing
component that could have any effect on it's display from an
application thread (not the EventDispatchThread itself), you should
add it to the event dispatch thread's queue via
SwingUtilities.invokeLater( Runnable ) or
SwingUtilities.invokeAndWait( Runnable ) so that it will be done on
the same thread that Swing itself uses. The good news is, even though
you are using Runnable, you don't have the overhead of actually
creating a new Thread since you are just calling the run method on the
already existing Swing thread.

There are a few exceptions to this general rule, most notably it is
safe to call repaint and revalidate, JTextComponent.setText and
JTextArea.append from any thread.

See http://mindprod.com/jgloss/threadsafe.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
 
Reply With Quote
 
Woebegone
Guest
Posts: n/a
 
      07-21-2004

> It's illegal because it will eventually conflict with whatever Swing is
> doing.


I second that: it's just a matter of time.
--
Sean.


 
Reply With Quote
 
Sam
Guest
Posts: n/a
 
      07-22-2004
Roedy Green <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..
> On 21 Jul 2004 08:13:34 -0700, (E-Mail Removed) (Yamin) wrote or
> quoted :
>
> >I was wondering how dangerous calling JLabel.setText from a thread
> >other than the event dispatching thread. I know its illegal, but its
> >in there. I'm looking at some code which does this, but so far it has
> >not caused any problems and its passed testing.

>
>
> Unlike the AWT, Swing is not threadsafe. You can't directly meddle
> with Swing components, or their backing data models from a second
> thread. The contract is, if you want to do anything to a Swing
> component that could have any effect on it's display from an
> application thread (not the EventDispatchThread itself), you should
> add it to the event dispatch thread's queue via
> SwingUtilities.invokeLater( Runnable ) or
> SwingUtilities.invokeAndWait( Runnable ) so that it will be done on
> the same thread that Swing itself uses. The good news is, even though
> you are using Runnable, you don't have the overhead of actually
> creating a new Thread since you are just calling the run method on the
> already existing Swing thread.
>



Let me see if I have this straight. Say you have an app that creates a
GUI to display something like the amount of data being processed by a
NIC card. To monitor this card, you start a thread, passing to it a
reference to the GUI you just created in the main thread
(EventDispatchThread, presumably). The monitoring thread needs to
continually update the GUI with data as it observes it.

Does the above reference mean the monitoring thread can't just update
the GUI even though it has a direct reference to it? For example, to
change a JTextBox on the GUI to say "100 packets received", do I have
to create runnable class, which nonetheless won't be invoked at the
start of a thread, which updates the JTextBox, and then make it a
parameter to either either invokeLater or invokeAndWait, instead of
updating JTextBox directly?

Is it possible for Sun have thought up a less intuitive way to do
this?

Regards,
Sam90
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-22-2004
On 21 Jul 2004 17:13:00 -0700, (E-Mail Removed) (Sam) wrote or
quoted :

>Does the above reference mean the monitoring thread can't just update
>the GUI even though it has a direct reference to it?


It has to pass a Runnable that does the gui poking to invokeLater.
There are some exception noted where you can safely do it yourself. I
can see why changing the text in a box is thread safe. All you are
doing is pointing the component to a new string -- an atomic
operation. So long as the paint routine makes it own copy of the
string, all should work.

Yet some other posters have said that these actions are not safe after
all, even if the JavaDoc claims they are.

It never hurts to use a Runnable. It is not that much overhead. It is
not as if you were starting a new thread. The advantage of doing the
Runnable is maintenance. If someone comes along later and changes the
code a little it will still work. Without the Runnable it could stop
working mysteriously, and thread problems are notoriously difficult to
reproduce and track down.


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
 
Reply With Quote
 
Matt Humphrey
Guest
Posts: n/a
 
      07-22-2004

<prior conv. snipped>

>
> Let me see if I have this straight. Say you have an app that creates a
> GUI to display something like the amount of data being processed by a
> NIC card. To monitor this card, you start a thread, passing to it a
> reference to the GUI you just created in the main thread
> (EventDispatchThread, presumably). The monitoring thread needs to
> continually update the GUI with data as it observes it.
>
> Does the above reference mean the monitoring thread can't just update
> the GUI even though it has a direct reference to it? For example, to
> change a JTextBox on the GUI to say "100 packets received", do I have
> to create runnable class, which nonetheless won't be invoked at the
> start of a thread, which updates the JTextBox, and then make it a
> parameter to either either invokeLater or invokeAndWait, instead of
> updating JTextBox directly?


The bigger issue is that the GUI in modern systems accounts for 75%-90% of
the code, so it's not just some little thing that gets updated every so
often. As a complex system in its own right, trying to synchronize it with
application code would be a total nightmare, would likely have bugs and
would have performance problems because of the constant lock checking. By
requiring it be single threaded (except for a couple of methods) Swing can
be much less complex, more robust and have better performance and fewer
opportunities for bugs. Keep in mind that it's only code that runs in
separate threads that needs to deferred to the Event thread. Many apps do
much of their work in the event handler itself where no update is required.

> Is it possible for Sun have thought up a less intuitive way to do
> this?


I have to admit it took a while to understand what was going on,
particularly because I was raised in the pre-GUI days where a program had
total control of the machine. But now I really like it and having written
many multithreaded (collaborative, distirbuted, etc, etc) systems I would
make the same design decision.

Cheers,

Matt Humphrey (E-Mail Removed) http://www.iviz.com/


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-22-2004
On Wed, 21 Jul 2004 21:36:30 -0400, "Matt Humphrey"
<(E-Mail Removed)> wrote or quoted :

> But now I really like it and having written
>many multithreaded (collaborative, distirbuted, etc, etc) systems I would
>make the same design decision.


Hear Hear! Any time you have race conditions possible, you get into
bugs that only show up on Christmas eve, and then disappear so you
can't nail them. invokeLater is a small penalty to pay for stability
and bug avoidance.

Everything happens on the Swing thread in nice orderly little chunks,
with no unpredictable interleaving.



--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
 
Reply With Quote
 
Yamin
Guest
Posts: n/a
 
      07-22-2004
Thanks for all the responses guys.
Yeah, I know about invokelater and what not. That's why I asked the
question as I knew of its illegality and how to write it properly.

Its not my code, and sometimes its a mission to get someone to change
something when its 'not broken'.

But I guess the general answer is that its VM specific.

Yamin

(E-Mail Removed) (Yamin) wrote in message news:<(E-Mail Removed). com>...
> Hey all,
>
> I was wondering how dangerous calling JLabel.setText from a thread
> other than the event dispatching thread. I know its illegal, but its
> in there. I'm looking at some code which does this, but so far it has
> not caused any problems and its passed testing.
>
> Basically, it's just a thread that updates the elapsed time. Don't
> ask me why its in its own thread...I didn't write it.
>
>
> Yamin

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
DANGER DANGER THIRD DAY CPU FAN FAILURE DANGER DANGER Skybuck Flying Windows 64bit 9 04-01-2010 10:33 PM
Danger Danger Will Robinson Vista SP1 Lloyd Sheen ASP .Net 2 03-19-2008 05:58 PM
Re: Link Link Link DANGER WILL ROBINSON!!! Kevin Spencer ASP .Net 0 05-17-2005 10:41 AM
danger JLabel.settext() in another thread Yamin Java 0 07-21-2004 03:16 PM
C++ danger to break due to its weight, fragmentation danger - C++0x Ioannis Vranos C++ 14 04-21-2004 12:19 AM



Advertisments