«

Why does this code hang for the specified 5 seconds (in the refresh
thread)before displaying anything? I have the sleep running in a
seperate thread but it causes everything to wait for it. The desired
result I am trying to accomplish here is to add another line of text
to the screen every 5 seconds. I'm not certain how to go about this
though. Any help understanding where I am going wrong here would be
greatly appreciated.

//-->Start Code
import java.applet.Applet;
import java.awt.Graphics;

public class test extends Applet
{
StringBuffer buffer;
refresh r;

public void init()
{
buffer = new StringBuffer();
addItem("initializing... ");
r = new refresh();
}

public void start()
{
addItem("starting... ");
r.start();
}

void addItem(String newWord)
{
buffer.append(newWord);
repaint();
}

public void paint(Graphics g)
{
g.drawString(buffer.toString(), 5, 15);
}

class refresh extends Thread
{
public void start()
{
try { refresh.sleep(5000); } catch(Exception e) { }
addItem("refreshed");
}
}
}
//--> End Code

If I put the refresh start() contents in a while(true) { } loop it
never displays anything. How do I have this loop running but allow
the main thread to continue?

Thanks much,
Tyler Kellen

"Tyler Kellen" wrote:

> Why does this code hang for the specified 5 seconds (in the refresh
> thread)before displaying anything? I have the sleep running in a
> seperate thread but it causes everything to wait for it. The desired
> result I am trying to accomplish here is to add another line of text
> to the screen every 5 seconds. I'm not certain how to go about this
> though. Any help understanding where I am going wrong here would be
> greatly appreciated.

a. You don't mess around with the start() method. Read the Thread API
again, also read the Sun tutorial about using threads.

b. Read about the single-threading behavior of the GUI. You do not
sleep in the event-handler thread, unless you want the GUI to freeze.

Tyler Kellen wrote:
> Why does this code hang for the specified 5 seconds (in the refresh
> thread)before displaying anything? I have the sleep running in a
> seperate thread but it causes everything to wait for it. The desired
> result I am trying to accomplish here is to add another line of text
> to the screen every 5 seconds. I'm not certain how to go about this
> though. Any help understanding where I am going wrong here would be
> greatly appreciated.
>
> class refresh extends Thread
> {
> public void start()
> {
> try { refresh.sleep(5000); } catch(Exception e) { }
> addItem("refreshed");
> }
> }

There's a big problem. You have overridden the thread's start()
method, so this Thread derivative can never actually be started.
All start() does is putthe calling thread to sleep for 5 secs.

I advise that you do not ever extend Thread. It creates too many
confusions like this mistake. Make your objects Runnable instead.

Steve

Steve Horsley <>
wrote on Sat, 13 Dec 2003 21:21:03 +0000:
> Tyler Kellen wrote:
>> class refresh extends Thread
>> {
>> public void start()
>> {
>> try { refresh.sleep(5000); } catch(Exception e) { }
>> addItem("refreshed");
>> }
>> }
> There's a big problem. You have overridden the thread's start()
> method, so this Thread derivative can never actually be started.
> All start() does is putthe calling thread to sleep for 5 secs.
> I advise that you do not ever extend Thread. It creates too many
> confusions like this mistake. Make your objects Runnable instead.

There's nothing wrong with extending Thread. He just needs to put
that code in run() instead of start().

Tyler, read java.lang.Thread's javadoc, and the parts of the Java
Tutorial about the Thread lifecycle.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
in a panic!--if he did, since I would know it really was Resuna, or a tiny
brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

Mark 'Kamikaze' Hughes wrote:

> Steve Horsley <>
> wrote on Sat, 13 Dec 2003 21:21:03 +0000:
>
>>Tyler Kellen wrote:
>>
>>> class refresh extends Thread
>>> {
>>> public void start()
>>> {
>>> try { refresh.sleep(5000); } catch(Exception e) { }
>>> addItem("refreshed");
>>> }
>>> }
>>
>>There's a big problem. You have overridden the thread's start()
>>method, so this Thread derivative can never actually be started.
>>All start() does is putthe calling thread to sleep for 5 secs.
>>I advise that you do not ever extend Thread. It creates too many
>>confusions like this mistake. Make your objects Runnable instead.
>
>
> There's nothing wrong with extending Thread. He just needs to put
> that code in run() instead of start().

It depends on what you mean by "wrong." It is a workable solution to
extend Thread by overriding its run() method to define the task the
thread is to perform. In that sense it is not wrong. It is poor
practice to do that, however, because (1) it is the wrong abstraction,
(2) it is somewhat inflexible, and (3) it is easy to muck it up (c.f.
the OP's problem).


John Bollinger

John C. Bollinger <>
wrote on Tue, 23 Dec 2003 08:58:37 -0500:
> Mark 'Kamikaze' Hughes wrote:
>> Steve Horsley <>
>> wrote on Sat, 13 Dec 2003 21:21:03 +0000:
>>>Tyler Kellen wrote:
>>>> class refresh extends Thread
>>>> {
>>>> public void start()
>>>> {
>>>> try { refresh.sleep(5000); } catch(Exception e) { }
>>>> addItem("refreshed");
>>>> }
>>>> }
>>>There's a big problem. You have overridden the thread's start()
>>>method, so this Thread derivative can never actually be started.
>>>All start() does is putthe calling thread to sleep for 5 secs.
>>>I advise that you do not ever extend Thread. It creates too many
>>>confusions like this mistake. Make your objects Runnable instead.
>> There's nothing wrong with extending Thread. He just needs to put
>> that code in run() instead of start().
> It depends on what you mean by "wrong." It is a workable solution to
> extend Thread by overriding its run() method to define the task the
> thread is to perform. In that sense it is not wrong. It is poor
> practice to do that, however, because (1) it is the wrong abstraction,
> (2) it is somewhat inflexible,

These complaints don't make any sense. It's a worker thread.
Subclassing Thread to do work is exactly what you should be doing, and
is the most precise way of saying what it is and what it does.
Implementing Runnable and passing it to a generic Thread object is
useful mainly if you want to subclass something else but also process a
thread, which is almost always a bad idea, leading to giant,
poorly-focused classes.

Why would you need any more "flexibility"? It's a thread. You start
it and it runs until the program ends (well, a correct version would,
Tyler's version will still just run once even if it's in the right
method). You're not going to do anything else with it.

Avoiding subclassing smacks of procedural programming habits. Those
unused to actually using OOP are understandably uncomfortable with
extending the behavior of an object, but that's what it's *for*.

> and (3) it is easy to muck it up (c.f.
> the OP's problem).

Not reading the documentation will do that. If I fail to read the
documentation for vi, I can't edit text, either. Oh no!

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
in a panic!--if he did, since I would know it really was Resuna, or a tiny
brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"Mark 'Kamikaze' Hughes" <> wrote in message
news: ...
/snip/
> These complaints don't make any sense. It's a worker thread.
> Subclassing Thread to do work is exactly what you should be doing, and
> is the most precise way of saying what it is and what it does.

It is generally accepted among the enlightment folks
that subclassing Thread is the wrong way. Get with
the times, you are thinking in the stone-age.

> Implementing Runnable and passing it to a generic Thread object is
> useful mainly if you want to subclass something else but also process a
> thread, which is almost always a bad idea, leading to giant,
> poorly-focused classes.

This thinking is either inane or insane, depending on whether
one is trying to analyze it or to design commercial-quality
object-oriented software. STOP IT!

> Why would you need any more "flexibility"? It's a thread. You start
> it and it runs until the program ends (well, a correct version would,
> Tyler's version will still just run once even if it's in the right
> method). You're not going to do anything else with it.

Using the Thread constructor that accepts a Runnable is
the correct way. Subclassing Thread is incorrect. Always.

> Avoiding subclassing smacks of procedural programming habits.

Total nonsense. Use subclasses where "IS-A" relationship makes
sense. An independent unit of work is a separate notion to the
*kind* of work being performed. "Thread" is the unit of work,
which has nothing to do with the "Runnable", which is the *kind*
of work to be done.

> Those
> unused to actually using OOP are understandably uncomfortable with
> extending the behavior of an object, but that's what it's *for*.

Those who understand OOP know when to use inheritance and
when to use composition. Apparently, you do not.

/snip/

xarax <>
wrote on Thu, 25 Dec 2003 16:34:54 GMT:
> "Mark 'Kamikaze' Hughes" <> wrote in message
> news: ...
> /snip/
>> These complaints don't make any sense. It's a worker thread.
>> Subclassing Thread to do work is exactly what you should be doing, and
>> is the most precise way of saying what it is and what it does.
> It is generally accepted among the enlightment folks
> that subclassing Thread is the wrong way. Get with
> the times, you are thinking in the stone-age.

You are a loon. I just want you to know that. Now I'm going to put
you in my killfile, because I know you'll never have anything useful to
say.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
in a panic!--if he did, since I would know it really was Resuna, or a tiny
brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

On Thu, 25 Dec 2003 16:34:54 GMT, "xarax" <> wrote or
quoted :

> Subclassing Thread is incorrect. Always.

I can think of a case where you would -- e.g. StoppableThread,
creating a kind of thread you can stop gently. You are correct though,
nearly always all you want is a light-weight Runnable.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On 26 Dec 2003 09:43:32 GMT, (Mark
'Kamikaze' Hughes) wrote or quoted :

> You are a loon. I just want you to know that. Now I'm going to put
>you in my killfile, because I know you'll never have anything useful to
>say.

I think you are overgeneralising. Just because you did not find that
post helpful does not mean you won't find anything he writes useful.

You are hurting yourself with such a post. It makes you sound like
one of those "entitlement brats" who figures the universe owes them a
solution to every problem neatly wrapped with a bow.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.