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

[Rodney Edmondson]

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)?"

 

[Ben_]

Hello,

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

Ben.

 

[Joseph Dionne]

OUCH! Each class brings a different part of the puzzle. But, reviewing
techniques of using threads is advisable.

 

[Chris Smith]

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

 

[Jose Rubio]

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

 

[ak]

I have been practicing writing and running to write the multi-threaded
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.

 

[Chris Smith]

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

 

[Chris Uppal]

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

 

[Chris Smith]

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

 

[Chris Uppal]

(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)

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

 

[Larry Coon]

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)?"

Technically, there's only one way: implementing Runnable.
But since Thread implements Runnable, you're implementing
Runnable either way.

The question then becomes one of which abstraction makes
the most sense.

 

[Jeremy]

Technically, there's only one way: implementing Runnable.
But since Thread implements Runnable, you're implementing
Runnable either way.

The question then becomes one of which abstraction makes
the most sense.

One deciding factor when programming for threads, and chosing the
mechanism to use, is if your system has some kind of class hierarchy.
Due to the non-support for multiple inheritance in Java, it is
impossible to have a custom thread that extends one class, and also
extends Thread. In this case the only option is Runnable.
On the other hand, if you do not have a class hierarchy it is arguably
easier to extend Thread.