From: markspace on
Here's a little issue from my code that bugging me right now. I have a
generic class that implements Callable<Void>

private class SortTask<T extends Comparable<? super T>>
implements Callable<Void>
{
...
@Override
public Void call()
throws Exception
{
...
}
}

When I use this class, the compiler doesn't seem to recognize that
SortTask implements Callable. It insists on issuing an unchecked warning.

SortTask task = new SortTask<T>( a, l, i - 1, counter );
executor.submit( task ); // Unchecked

To alleviate this warning I made a new variable and assigned "task" to
that. However this makes me suspicious that there's a hidden cast in
there now, and I'd prefer not to do that because the algorithm is very
time critical.

SortTask task = new SortTask<T>( a, l, i - 1, counter );
Callable<?> call = task; // Hidden cast?
executor.submit( call );

So I'm wondering if there's a better way to do this. If I make SortTask
non-generic, then the compiler spots the "implements Callable<Void>"
just fine, and doesn't complain. This strikes me as a bug in the
compiler. But it also leads to other problems with generics, so I think
I need to use the generic version of SortTask for now.

If anyone could point out a better way of doing this, I'd appreciate it.
From: Steven Simpson on
On 15/12/09 17:55, markspace wrote:
> When I use this class, the compiler doesn't seem to recognize that
> SortTask implements Callable. It insists on issuing an unchecked
> warning.
>
> SortTask task = new SortTask<T>( a, l, i - 1, counter );
> executor.submit( task ); // Unchecked

Your 'task' variable is declared without <T> (or <?>?). Does that make
a difference?

SortTask<T> task = ...

Looks like the compiler doesn't recognise that SortTask implements
Callable<Void>, i.e. all generics have been stripped off by lack of <>,
including inherited details, even though the generic parameter doesn't
affect those.

--
ss at comp dot lancs dot ac dot uk

From: Roedy Green on
On Tue, 15 Dec 2009 09:55:42 -0800, markspace <nospam(a)nowhere.com>
wrote, quoted or indirectly quoted someone who said :

> SortTask task = new SortTask<T>( a, l, i - 1, counter );

What happens with:

SortTask<T> = new SortTask<T>( a, l, i - 1, counter );
--
Roedy Green Canadian Mind Products
http://mindprod.com
The future has already happened, it just isn�t evenly distributed.
~ William Gibson (born: 1948-03-17 age: 61)
From: markspace on
Steven Simpson wrote:

> On 15/12/09 17:55, markspace wrote:
>> SortTask task = new SortTask<T>( a, l, i - 1, counter );
>> executor.submit( task ); // Unchecked

>
> Your 'task' variable is declared without <T> (or <?>?). Does that make
> a difference?


Well that was annoying. I refactored from a SortTask that wasn't
generic. After eliminating the all the errors, I was left with a
warning on the executor.submit() invocation. You'd think maybe the
compiler would complain about the raw type instead?

Anyhoo, that was it. Thanks for spotting that.
From: Donkey Hottie on
On 15.12.2009 19:55, markspace wrote:
> Here's a little issue from my code that bugging me right now. I have a
> generic class that implements Callable<Void>
>
> However this makes me suspicious that there's a hidden cast in
> there now, and I'd prefer not to do that because the algorithm is very
> time critical.
>

Is a cast somehow a runtime operation? In C it used to be a compile time
operation, and does not add any runtime penalty. A warning will be
issued, but any extra code hardly will be generated. I may be wrong with
Java, though.

--
Your supervisor is thinking about you.