• Post Reply Bookmark Topic Watch Topic
  • New Topic

Need Generics Help With Callable Implementation and ExecutorService  RSS feed

 
Michael Schulz
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Folks!

I'm running into a compiler warning when using generics with an Implementation of the Callable interface in conjunction with an ExecutorService. (The implementor of the Callable interface is a node in a tree structure.)

I've attached a shortened version of the code below. I'm getting the warning on the line that calls the invokeAll() method on the ExecutorService: "Type safety: Unchecked invocation invokeAll(Collection) of the generic method invokeAll(Collection<Callable<T>> of type ExecutorService"

I've tried a wide variety of generics tagging to avoid this warning, but can't seem to find a valid approach that solves the warning and still allows me to treat the "children" collection as a collection of CallableNode objects rather than just a Collection of Callable objects.

Any help would be appreciated!
Mike



[ June 27, 2006: Message edited by: Michael Schulz ]
[ June 27, 2006: Message edited by: Michael Schulz ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem is that the T in Callable<T> is not declared. CallableNode implements Callable rather than implementing Callable<Something>. Either generify CallableNode or implement Callable<Object> instead. A generic version would look something like this:



As opposed to a version where you declare what E is:



The advantage of the first is obviously that it may return anything. However, if CallableNode itself must always return an Object or some other upper bounds and cannot be generic then you need to declare what that is, in the above example it was an Object.
 
Michael Schulz
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ken, thanks for your reply!

I understand what you're saying, (and you're correct regarding the need to specify the T for Callable<T>), but that still doesn't address my problem with needing ultimately to pass a Collection<CallableNode> to the ExecutorService's invokeAll() method which expects a Collection<Callable<T>>

If I update the code (as below) to specify a particular class for T (in this case CallableNodeReturn), I now have an error rather than a warning when trying to execute invokeAll(): "The method invokeAll(Collection<Callable<T>>) in the type ExecutorService is not applicable for the arguments (Collection<CallableNode>) ".

Mike



[ June 27, 2006: Message edited by: Michael Schulz ]
[ June 27, 2006: Message edited by: Michael Schulz ]
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Indeed. The signature of ExecutorService.invokeAll() appears to be too restrictive. Looking at the source code I'm unable to find any reason it shouldn't be Collection<? extends Callable<T>> instead of Collection<Callable<T>>. Basically, you're going to have to work around it with something like this:

 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually you could probably just wrap it with Collections, I don't think invokeAll() needs to mutate the Collection but you should look into that before doing it.

 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Furthermore, I was correct that the method signature is too restrictive. It's already been fixed, I'm not sure what release mustang(b51) is but I don't see the change in 1.5.7.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6267833

EDIT: Apparently mustang is 1.6. So yeah, you'll have to work around it for now. If you move to 6 in the future you won't have this problem.
[ June 27, 2006: Message edited by: Ken Blair ]
 
Michael Schulz
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ken!

Thanks for your help! It's an ugly solution, but until Java 6 there doesn't seem to be much other choice.

Thanks!
Mike
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!