• Post Reply Bookmark Topic Watch Topic
  • New Topic

which one is the better way to create a thread

 
abhay jain
Ranch Hand
Posts: 130
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
implementing runnable interface is the better way than extending Thread class , is that true ?? why ?
 
Stephan van Hulst
Bartender
Posts: 6583
84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because the Java designers (with all due respect) screwed up when they decided Thread should be Runnable, and have a run() method. It's simply not what the concept of a Thread stands for.

You should keep things simple. Is there any reason you want to include the extra functionality that the Thread class provides?

Also, you shouldn't use a Thread directly anyway. Use an ExecutorService instead.
 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never use Runnable, use Callable instead. It allows return values and exceptions to be throw, but otherwise does exactly the same thing. Using an ExecutorService more or less forces you into doing this but it also introduces the concept of a Future to wrap the future result of the Callable.
 
Stephan van Hulst
Bartender
Posts: 6583
84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never is a bit strong don't you think? What if you don't have any return value, or exceptions to throw? Why would you force yourself to use a Callable if you can use a simpler and more widely known interface? ExecutorService can use Runnables just fine.
 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never isn't a bit strong. Look at the two interfaces and you will find them 100% identical except for the two points mentioned. Basically Callable is an upgraded version of Runnable, and I predict that Runnable will be demoted to legacy status fairly soon.

If you don't have anything to return or any exceptions to throw then don't. Callable doesn't force you to, it allows you to. Switching from Runnable to Callable in the future might be a headache so use Callable from day 1.

Return type is defined using standard generic pattern so there is nothing new in that either.
 
Paul Clapham
Sheriff
Posts: 21875
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But if I have to implement "public V call()" then I have to choose a return type and write code to return something of that type, don't I? Sure, I could choose Object for V and then return null, but that feels like I'm being forced to return something.
 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using generics you can define Void as type, so the difference comes down to one line. Just add return null; as the last line in call() and you're good to go. No thinking involved.

Don't use Object in generic patterns, but that is a separate discussion.

But yes, it does require you to add a return as Void is not the same as void. I forgot about that little detail, since I never use that type. Why this the case eludes me, because declaring the type as Void says you don't care about the return value. Normally I use Integer as return type (with autoboxing you can just use int) and return a status code.
 
Joe Areeda
Ranch Hand
Posts: 332
2
Java Netbeans IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
abhay jain wrote:implementing runnable interface is the better way than extending Thread class , is that true ?? why ?
I don't mean to discount the other discussions but to address your question directly:

Since Java does not have multiple inheritance (in it's pure form) I think it's the difference between having Thread as a base class or something more application specific which implements the Runnable interface.

If your design derives the background job from Object and is not used as a base class for anything (and never will) I don't think it makes much difference.

If your design has a base class and then derives a Class that runs in the event loop thread and another that runs in the background then the Runnable is much cleaner because only the one sub-class can be started in the background yet all the real work can be done in the base class.

This is just the way I look at things, I don't claim it's the best or the only way.

Joe
 
Stephan van Hulst
Bartender
Posts: 6583
84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because Void is no special type that causes the language to work differently than it would with any other type. Void is simply an uninstantiable type that provides no useful functionality (other than being a placeholder). The only valid value is the null reference.

So yes, this makes it a valid return type for generic methods, if you have nothing to return.

However, I don't think there's *any* reason for Runnable to become legacy, since there is nothing inherently wrong with it, and it's not made obsolete by the Callable interface either, since it provides one important advantage. It's simple. It makes the code easier to read. Maybe not by a lot, but why wouldn't I take that little bit of extra simplicity if I don't have any reason to use the ability to throw exceptions or return a value?

I also don't foresee a lot of hardship if the Runnable interface *does* become obsolete or deprecated. You can simply make your old Runnables implement Callable as well, and delegate to the run method.
 
Paul Clapham
Sheriff
Posts: 21875
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Philip Grove wrote:Using generics you can define Void as type...


Yeah, I vaguely remembered some feature like that but I didn't try googling it. Also I thought you would most likely enlighten me.
 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:
However, I don't think there's *any* reason for Runnable to become legacy, since there is nothing inherently wrong with it, and it's not made obsolete by the Callable interface either, since it provides one important advantage. It's simple. It makes the code easier to read. Maybe not by a lot, but why wouldn't I take that little bit of extra simplicity if I don't have any reason to use the ability to throw exceptions or return a value?


Very much of topic here, but hopefully this branch ends soon.

Is there something inherently wrong with StringTokenizer, which is a legacy class? As far as I can tell there is nothing wrong with it, there are just better ways of doing what it used to be the only way of doing.

I don't think we'll agree on what is best Runnable or Callable, so one option is to agree to disagree which is the solution I will go for.
 
Stephan van Hulst
Bartender
Posts: 6583
84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agreed. And if they move Runnable to the archives you can tell me "I told you so" :P
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!