Unchecked Exception using 1.5 Concurrent Libraries

Question

Sorry to post this here, but it IS related to generics. I'm either doing something wrong, or the concurrent libraries are missing some methods in the ThreadPoolExecutor class.
I'll try and be brief. When I compile my multi-threaded application with lint on, I get the following error:
"TransactionsByStore.java:309: warning: [unchecked] unchecked conversion
found : java.util.concurrent.LinkedBlockingQueue
required: java.util.concurrent.BlockingQueue<java.lang.Runnable>
threadPool = new ThreadPoolExecutor(threadCount, threadCount, threadTimeout, TimeUnit.SECONDS, threadQueue);"
The problem is my "threadQueue" class. It is of type LinkedBlockingQueue<java.util.concurrent.Callable> since Callable allows the class to return something from the "call" method. It appears that most classes in the concurrent libraries prefers Callable classes over Runnable, but the constructor for a ThreadPoolExecutor appears to only accept a thread queue that holds Runnables. That doesn't seem correct.
Does anyone know if there is something that I am doing wrong here, or is this just a current limitation of the ThreadPoolExecutor class?
Thanks.

Answer 1

The problem is my "threadQueue" class. It is of type
LinkedBlockingQueue<java.util.concurrent.Callable>
since Callable allows the class to return something
from the "call" method. It appears that most classes
in the concurrent libraries prefers Callable classes
over Runnable, but the constructor for a
ThreadPoolExecutor appears to only accept a thread
queue that holds Runnables. That doesn't seem
correct.
Does anyone know if there is something that I am
doing wrong here, or is this just a current
limitation of the ThreadPoolExecutor class?OK, so I just did some reading and I now better understand the context of your question:
* ThreadPoolExecutor is an ExecutorService, not just an Executor, so it handles Callables in addition to Runnables
* You're taking the slightly unusual step of constructing your own instance, presumably because you've determined none of the predefined ExecutorServices that the Executors factory class creates are suitable for your task?
* As you wish to use the ThreadPoolExecutor to execute Callables, you want to know why the constructor takes BlockingQueue<Runnable> rather than BlockingQueue<Callable>
So firstly, this question really has nothing to do with generics. Callable isn't a Runnable and as such there's no way you're ever going to be able to pass a BlockingQueue<Callable> into this method. Therefore it's a question about the design of the concurrency libraries. As such you'll probably get much better quality answers in a forum dedicated to that subject.
Having said that:
From what I see the ExecutorService.submit() methods that support Callables are all implemented in the AbstractExecutorService class that is the superclass for ThreadPoolExecutor.
So I read the source code for that class. Turns out every Callable passed to submit() is wrapped in a FutureTask, which is a class that imlements Future<V> and Runnable. This makes perfect sense if you think about it - given that this ExecutorService executes things asynchronously, clearly a Future<V> is required if you want to be able to actually get at the result.
Thus since Callables are wrapped in a class that's Runnable inside the ExecutorService, that's how it is able to handle Callables using a BlockingQueue<Runnable>.
So... is it important to you that the queue you pass in is a BlockingQueue<Callable> or can you simply make it a BlockingQueue<Runnable>?
You're never going to be able to constrain the type of the BlockingQueue to be anything stricter than Runnable, BTW. This is because the ThreadPoolExecutor executes Runnables as well as Callables, so if you were allowed to pass in a BlockingQueue<FutureResult> (for example) then it wouldn't work because the execute(Runnable) method wouldn't be able to add the Runnable to the queue without wrapping it in a spurious FutureResult.