Welcome to the Ranch, srinivasarao. ___________________________________________________________________________ By using an object implementing Runnable we have decoupled the machinery to perform a task (the thread object) from the task itself (the Runnable object). Now we can store or transmit the tasks to be carried out by a thread. In theory there is also the following risk for an object extending Thread: synchronized instance methods in such object might also to have to contend for the lock against the instance methods that were declared synchronized in the Thread class! [ September 22, 2003: Message edited by: Jose Botella ]
Inheritance semantically is analogous to "a kind of" relationship. There are classes where you want thread functionality but where the inheritance relationship doesn't make much sense. It is better in those cases to implement Runnable. Also if your class needs to extend another class, and yet access thread functionality, the only way to achieve this (since Java has no multiple inheritance) is to implement Runnable in addition to extending the parent class.
Just adding my comments to already long discussion. Weather to extend Thread or implemnt runnable depends on what exactly you are doing inside your run() method. Lets take 2 cases : 1. You extend your class from the Thread class. Here there is no interaction between the run method and the class members, because the run method from the parent class is used. i.e. if you want to access your class members inside the run method it cannot be done, unless you override the method in the parent Thread class. 2. You implement the runnable. Here since you are writing the run() in your class itself. The run() method has full access to your class members. So there can be full interaction between the run method and the class. -Kaustubh.
Kaustubh. Mumbai, India.
Joined: Sep 02, 2003
Originally posted by Kaustubh Patil: Here there is no interaction between the run method and the class members, because the run method from the parent class is used. i.e. if you want to access your class members inside the run method it cannot be done, unless you override the method in the parent Thread class.
Why should anyone extend Thread class without overriding run() method in real world(except for theory purposes).
In general I prefer to implment Runnable rather than extend Thread. However there are two exceptions to this:
Cases where the code is very short. Instead of
I prefer to save a line:
Or even just
Cases where I want to add some useful functionality to the Thread class, while still retaining the ability to use my new class for different Runnable implementations. E.g. I found that when I want to test a multi-threaded application, and an exception is thrown from a thread which I spawned for teting purposes, JUnit doesn't do a good job of catching and reporting this exception, since it's in a different thread than the one JUnit is monitoring. So I made a TestThread subclass which collects any exceptions thrown during run() and makes it easier to report them later. I suppose I could have made an abstract Runnable class which does the same thing, but the methods I was adding were related to thread control and monitoring more than they were to the actual Runnable task that was being implemented, so made logical sense to put my code in Thread subclass. And this way it can still be plugged in to any Runnable, for max flxibility. If I'd made an abstract class implementing Runnable, then any time I used it I couldn't inherit from any other class; I'd have to extend my TestRunnable class. Ugh. Putting my implementation in the Thread subclass kept the Runnable interface flexible.
Happens all the time in my code. Here the Thread is an anonymous inner class, which almost by definition is going to be fiddling with its outer class's stuff. If the body of run() is more than a line or three, it doesn't belong in an anonymous class, so I'll move it to a method in the outer class, and call it from run(). So single-line run() bodies are very common for me.