Type parameters and anonymous subclasses

[John C. Bollinger]

Consider this method:

List<String> createStringList(final String[] array) {
return new AbstractList<String>() {
public int size() {
return array.length;
}

public String get(int i) { // Note the return type
return array;
}
};
}

The code compiles without error or warning with Sun's 1.5.0 compiler,
but Eclipse 3.1 M4 complains (a warning) about an unchecked type
conversion being required to convert String to the return type of the
superclass' method (E). Is M4's support for generics just lacking in
this regard? I'm having trouble seeing how there is any unsafe cast
required, but on the other hand it also seems that I'm leveraging the
new covariant return type feature to get what I want at all, and that
doesn't feel right.

 

[Chris Uppal]

The code compiles without error or warning with Sun's 1.5.0 compiler,
but Eclipse 3.1 M4 complains (a warning) about an unchecked type
conversion being required to convert String to the return type of the
superclass' method (E). Is M4's support for generics just lacking in
this regard? I'm having trouble seeing how there is any unsafe cast
required, but on the other hand it also seems that I'm leveraging the
new covariant return type feature to get what I want at all, and that
doesn't feel right.

Interesting example ;-) At first sight it looks innocuous, but I see what you
mean about the covariant return. It feels unnatural to me too. There's some
sense, which I can't quite articulate, of it crossing over levels of
abstraction.

Still, I don't see any reason why it should be flagged as dangerous. It might
be worth unpicking some of the layers of syntactic sugar to see if the warning
goes away once the code is translated into a simpler semantic equivalent.

OTOH, the following feels somewhat better to me (it avoids the covariant stuff,
and doesn't tangle abstraction levels). Maybe M4 would accept it ?

List<String> createStringList(String[] array)
{
return createList(array);
}

<E> List<E> createList(final E[] array)
{
return new AbstractList<E>()
{
public int size() { return array.length; }
public E get(int i) { return array; }
};
}

-- chris

 

[John C. Bollinger]

OTOH, the following feels somewhat better to me (it avoids the covariant stuff,
and doesn't tangle abstraction levels). Maybe M4 would accept it ?

List<String> createStringList(String[] array)
{
return createList(array);
}

<E> List<E> createList(final E[] array)
{
return new AbstractList<E>()
{
public int size() { return array.length; }
public E get(int i) { return array; }
};
}

M4 is just fine with that, thanks. As far as I can tell, 1.5 doesn't
have any better alternative, unless it's what I started with; I'd love
to hear about any other good alternatives, though. I had even begun to
write something similar to your suggestion for the real project that got
me going on this, but I decided that it was too much extra complication.
(The real code has a context and an underlying data structure a little
more complicated than the example's, and its applicability is rather
more specific.)

Thanks again.