views:

3715

answers:

5

Executor seems like a clean abstraction. When would you want to use Thread directly rather than rely on the more robust executor?

+2  A: 

There is no advantage to using raw threads. You can always supply Executors with a Thread factory, so even the option of custom thread creation is covered.

skaffman
+1  A: 

I use Thread when I need some pull based message processing. E.g. a Queue is take()-en in a loop in a separate thread. For example, you wrap a queue in an expensive context - lets say a JDBC connection, JMS connection, files to process from single disk, etc.

Before I get cursed, do you have some scenario?

Edit:

As stated by others, the Executor (ExecutorService) interface has more potential, as you can use the Executors to select a behavior: scheduled, prioritized, cached etc. in Java 5+ or a j.u.c backport for Java 1.4.

The executor framework has protection against crashed runnables and automatically re-create worker threads. One drawback in my opinion, that you have to explicitly shutdown() and awaitTermination() them before you exit your application - which is not so easy in GUI apps. If you use bounded queues you need to specify a RejectedExecutionHandler or the new runnables get thrown away.

You might have a look at Brian Goetz et al: Java Concurrency in Practice (2006)

kd304
I was implementing a polling queue using a Thread, when I noticed I can get exactly the same functionality but easier with an Executor (easier to detect when it's done).
ripper234
+1  A: 

You don't use Thread unless you need more specific behaviour that is not found in Thread itself. You then extend Thread and add your specifically wanted behaviour.

Else just use Runnable or Executor.

nojevive
You can always return your custom Thread object from a ThreadFactory, and pass that to the Executor.
skaffman
+5  A: 

To give some history, Executors were only added as part of the java standard in Java 1.5. So in some ways Executors can be seen as a new better abstraction for dealing with Runnable tasks.

A bit of an over-simplification coming... - Executors are threads done right so use them in preference.

Pablojim
Well, Erlang is threads done right, but Executors are about as good as it'll get in java...
skaffman
A: 

Well, I thought that a ThreadPoolExecutor provided better performance for it manages a pool of threads, minimizing the overhead of instantiating a new thread, allocating memory...

And if you are going to launch thousands of threads, it gives you some queuing functionality you would have to program by yourself...

Threads & Executors are different tools, used on different scenarios... As I see it, is like asking why should I use ArrayList when I can use HashMap? They are different...

SoulWanderer