THREADS

[suma yellappa reddy]

hi,
Please if any one can clarify my doubt.
Threads can be created by using Running interface or thread class.
My doubt is What is the difference b/w the two? And
Which method should be used when?
This question was asked in one of my interview.
So please do mail me about this soon.
My id is [email protected]
[email protected]

[David Crossett]

Yes. Im sure there are 'deeper' answers than this, but the main reason I know of is this: Since you can only extends one thing ( single inheritance ), what happens if you want to create threads in a class that creates a JFrame (by extendsing JFrame) ? Well, this way you can implement "Runnable" (to create threads) and still extend whatever you want (for inheritance).

[Mark Vedder]

Thread is a class, and therefore must be extended (i.e. sub classed) whereas Runnable is an interface, and therefore implemented. Since in Java a class can only extend one class (but multiple interfaces), you would have to use Runnable anytime you want your class -- that is already extending another class -- to be executable by a thread. For example, if I need a multithreaded capable applet, I would define it as:
public class MyApplet extends Applet implements Runnable
Beyond that obvious case of when you must use Runnable, the question then becomes one or which choice provides more clarity in your solution.
The Runnable class in the Java API has this to say on the subject:

In most cases, the Runnable interface should be used if you are only planning to override the run() method and no other Thread methods. This is important because classes should not be subclassed unless the programmer intends on modifying or enhancing the fundamental behavior of the class.

There can be a lot of discuss and debate beyond these basic considerations. But that, at a high-level, is the difference.

[Dirk Schreckmann]

Moving this to the Threads and Synchronization forum...

[paul wheaton]

Ny aplogies for getting to this kinda late ...
I think that you should always extend Thread and never implement Runnable.
After all, your thread stuff IS A thread. If you have a case where you need to do some thread stuff inside of a class that is all about something else, well, that just screams (to me) INNER CLASS!

[Jim Yingst]

Mmmm, I disagree, Paul. Much of the time it makes little difference, especially when the program is simple. But as things get more complex, I think it's advantageous to conceptually separate the task to be done (a Runnable) from the worker doing it (a Thread). This shows up in the new java.util.concurrent package in JDK 1.5. Among other things, this provides convenient thread pool implementations (or more generally, ExecutorServices) that you can configure indepenently of the Runnable tasks to be executed. Here's a demo:

import java.util.concurrent.*;
public class UtilConcurrentTest {
    public static void main(String[] args) throws InterruptedException {
        int numThreads = 4;
        int numTasks = 20;
        ExecutorService service = Executors.newFixedThreadPool(numThreads);
        // do some tasks:
        for (int i = 0; i < numTasks; i++) {
            service.execute(new Task(i));
        }
        service.shutdown();
        log("called shutdown()");
        boolean isTerminated = service.awaitTermination(60, TimeUnit.SECONDS);
        log("service terminated: " + isTerminated);
    }

    public static void log(String msg) {
        System.out.println(System.currentTimeMillis() + "\t" + msg);
    }
    private static class Task implements Runnable {
        private final int id;
        public Task(int id) {
            this.id = id;
        }
        public void run() {
            log("begin:\t" + this);
            try { Thread.sleep(1000); } catch (InterruptedException e) {}
            log("end\t" + this);
        }
        public String toString() {
            return "Task " + id + " in thread " + Thread.currentThread().getName();
        }
    }
}

When using java.util.concurrent, you basically never want to start() a Thread yourself. Instead you obtain an Executor (typically an ExecutorService) and tell it to execute the task for you. The execute(Runnable) method expects, well, a Runnable. You can pass it a Thread, since a Thread is a Runnable, but that's needlessly confusing IMO - why create a Thread if you're not going to call its start() method, but instead use library which will find some other Thread to execute run()? What if there are junior programmers on the project - they might see your new Thread subclass and figure they're supposed to call it's start() method themselves, ignoring the nifty thread pool you've set up. It's better IMO to encourage everyone to start thinking of workers and tasks as two separate entities. Define a task to be done using a Runnable; execute it using a Thread (pre 1.5) or Executor (1.5+).
I know 1.5 isn't exactly in widespread use yet, but it will be eventually. And there are other concurrency libraries out there - googling "java ThreadPool" gets multiple libraries that have a class of that name. They all seem to be predicated on the idea that you create a Runnable fist, and use the library to get it to execute somehow. Even outside of java 1.5, there's reason to encourage people to separate tasks from workers.