• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Frank Carver
  • Henry Wong
  • Ron McLeod
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Himai Minh

Need Generics Help With Callable Implementation and ExecutorService

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
We find this kind of rampant individuality very disturbing. But not this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic