Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why do Java offers two different ways to write the multi-threaded Java programs?

Reply
Thread Tools

Why do Java offers two different ways to write the multi-threaded Java programs?

 
 
Rodney Edmondson
Guest
Posts: n/a
 
      12-05-2003
I have been practicing writing and running to write the multi-threaded
Java programs; Thread class and implements the Runnable interface. My
question is as follows; "Why do Java offers two different ways
(extends from the Thread class and implements the Runnable
interface)?"
 
Reply With Quote
 
 
 
 
Ben_
Guest
Posts: n/a
 
      12-05-2003
Hello,

You may want to read the chapter related to threading in Thinking In Java
(and the rest of the book as well .

Ben.


 
Reply With Quote
 
 
 
 
Joseph Dionne
Guest
Posts: n/a
 
      12-05-2003
OUCH! Each class brings a different part of the puzzle. But, reviewing
techniques of using threads is advisable.

Ben_ wrote:
> Hello,
>
> You may want to read the chapter related to threading in Thinking In Java
> (and the rest of the book as well .
>
> Ben.
>
>


 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      12-05-2003
Rodney Edmondson wrote:
> I have been practicing writing and running to write the multi-threaded
> Java programs; Thread class and implements the Runnable interface. My
> question is as follows; "Why do Java offers two different ways
> (extends from the Thread class and implements the Runnable
> interface)?"


No good reason. It's generally accepted that unless you're trying to
change the basic nature of the thread itself (quite rare), you should
simply implement Runnable to provide code for the thread to run.
Extending thread is substantially messier, and is just the wrong
abstraction.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
Jose Rubio
Guest
Posts: n/a
 
      12-05-2003
And another reason is that you can only inherit once, but can implement
multiple interfaces. If you inherit from Thread just to make your class run
in a separate thread, you loose the ability to inherit from a superclass
that you might really need to extend.

Jose

"Chris Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)4.net...
> Rodney Edmondson wrote:
> > I have been practicing writing and running to write the multi-threaded
> > Java programs; Thread class and implements the Runnable interface. My
> > question is as follows; "Why do Java offers two different ways
> > (extends from the Thread class and implements the Runnable
> > interface)?"

>
> No good reason. It's generally accepted that unless you're trying to
> change the basic nature of the thread itself (quite rare), you should
> simply implement Runnable to provide code for the thread to run.
> Extending thread is substantially messier, and is just the wrong
> abstraction.
>
> --
> www.designacourse.com
> The Easiest Way to Train Anyone... Anywhere.
>
> Chris Smith - Lead Software Developer/Technical Trainer
> MindIQ Corporation



 
Reply With Quote
 
ak
Guest
Posts: n/a
 
      12-05-2003
> > I have been practicing writing and running to write the multi-threaded
> > Java programs; Thread class and implements the Runnable interface. My
> > question is as follows; "Why do Java offers two different ways
> > (extends from the Thread class and implements the Runnable
> > interface)?"


Extending Thread gives you possibility to make simple things quckly.
Implementing Runnable gives you many possibilities:
For example you could have some kind worker thread which all time
fetches next Runnable from some queue and then calls Runnble.run().
So you can make many jobs without creating many threads.


____________

http://reader.imagero.com the best java image reader.


 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      12-05-2003
ak wrote:
> Extending Thread gives you possibility to make simple things quckly.
> Implementing Runnable gives you many possibilities:
> For example you could have some kind worker thread which all time
> fetches next Runnable from some queue and then calls Runnble.run().
> So you can make many jobs without creating many threads.


The real question, though, is this: does extending Thread really make
anything simpler? For someone who knows the language, it's just as easy
to write

new Thread(new Runnable() {
public void run()
{
...
}
}).start();

, and the added flexibility will be very much appreciated. On the other
hand, for someone struggling with the language, the code

new Thread() {
public void run()
{
...
}
}.start();

is more mystical, because implementation inheritance from Thread is an
extra level of complexity that doesn't need to be dealt with. Not only
that, but it's a particularly poor example of the use of implementation
inheritance at that!

So the only real reasons I can see to extend Thread are:

1. Some older books taught it that way before it became widely
understood that implementing Runnable is better, so it's the only thing
some people know, and

2. I guess you save a few keystrokes.

In the end, it was clearly a mistake. It doesn't do any terrible amount
of harm, but it really never should have happened.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      12-06-2003
Chris Smith wrote:

> So the only real reasons I can see to extend Thread are:
> [2 things snipped]


3. Thread-specific data (thread-local storage).

which is a special case of:

4. Thread-specific behaviour.

You don't need these things *often* but when you do...

The design is *not* a mistake. (And I don't often make such strong claims
about the quality of the Java standard libraries -- not positive ones anyway


-- chris


 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      12-06-2003
Chris Uppal wrote:
> Chris Smith wrote:
>
> > So the only real reasons I can see to extend Thread are:
> > [2 things snipped]

>
> 3. Thread-specific data (thread-local storage).


(Incidentally, this is generally done with java.lang.ThreadLocal, which
is intended for that purpose. Any reason you'd want to switch to
extending Thread instead for this? Nevertheless...)

> which is a special case of:
>
> 4. Thread-specific behaviour.
>
> You don't need these things *often* but when you do...


Sorry to be confusing. My comments should be read in the context of the
thread at that point. I was specifically referring to extending the
Thread class in order to define the code that should be executed by some
specific thread.

> The design is *not* a mistake.


Are you talking about having Thread implement Runnable and define a
public run() method as a result? How is that at all relevant to
defining new behaviors for the Thread class by implementation extension?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      12-08-2003
Chris Smith wrote:

> > 3. Thread-specific data (thread-local storage).

>
> (Incidentally, this is generally done with java.lang.ThreadLocal, which
> is intended for that purpose. Any reason you'd want to switch to
> extending Thread instead for this? Nevertheless...)


The same reason that I'd use inheritance if I wanted to extend, say, TreeSet
with data that was intended to be "part of" the object. I might use an
external Map of some sort if I wanted to have data that was only "associated
with" the object. Similarly for Threads. (There's also the performance
issue -- relevant here more than it normally is, because you may be using
"thread local storage", however it's implemented, to avoid synchronization
bottlenecks. In such cases extending Thread might be the implementation
strategy of choice even if the extra data were conceptually only "associated
with" the thread)


> > 4. Thread-specific behaviour.
> >
> > You don't need these things *often* but when you do...

>
> Sorry to be confusing. My comments should be read in the context of the
> thread at that point. I was specifically referring to extending the
> Thread class in order to define the code that should be executed by some
> specific thread.


Right. I had missed your meaning. However your post does leave the impression
(even with hindsight) that your advice was that subclassing Thread was simply
an anachronism.

With the clarification, I think you were saying that it is anachronistic *in
the context of* creating a thread with a nested class and an "inline" run()
method. I.e. that a valid subclass of Thread is going to be a top level class.
If so, then I entirely agree.

-- chris


 
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
Ramzan Offers, Eid Offers, 50% off Smart Shoppers Digital Photography 0 09-15-2009 12:49 PM
Collection of strings - two different ways Peppy Java 4 05-24-2007 04:23 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
different ways to creating two lists from one Todd MacCulloch Python 3 10-29-2003 09:16 PM



Advertisments