This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js and have Paul Jensen on-line!
See this thread for details.
Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

THREADS  RSS feed

 
suma yellappa reddy
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 sushmaysr@yahoo.co.in
sushmay_reddy@rediffmail.com
 
David Crossett
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 624
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving this to the Threads and Synchronization forum...
 
paul wheaton
Trailboss
Posts: 22521
Firefox Browser IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

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.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!