Covariant Return Types in 1.5 - doesn't work with Generics?

[Robert Elliot]

I'm trying to compile the following code:

public class Foo {

public List<Object> foo() {
return new ArrayList<Object>();
}
}


public class FooExt extends Foo {

public List<String> foo() {
return (List<String>) super.foo();
}
}

The compiler doesn't like it at all; it objects both:

1) to the cast from List<Object> to List<String>, and

2) to over-riding Foo.foo()'s List<Object> return type with
List<String>.

I don't really understand what the problem is; Java 1.5 supports
covariant return types, so

public String foo()

can over-ride

public Object foo()

- what's the difference when over-riding the generic return type?

Equally, Java will happily let me try to do a cast (String) Object;
it'll fall over at runtime if the thing isn't a String. So why can't
I do a cast (List<String>) List<Object> and have it fall over at
runtime if the List contains things that aren't Strings?

Cheers for any help,

Rob

 

[Neal Gafter]

List<String> is not a subtype of List<Object>. See
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf section 3.

 

[Robert Elliot]

Drat Google - by the time this gets posted someone will have answered
it my original post. Eventually found a full explanation of Generics
here:

http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf

so I've found the answer to my question. Apologies.

Not sure I agree with the decisions on generics; since they had
already encountered the issues with arrays, why go for a different
solution with generics? I'd happily take the risk of getting a
runtime exception if I was stupid enough to cast an ArrayList<Integer>
to List<Object> and try to add a String; after all that's exactly what
happens if I cast an Integer[] to an Object[] and try to set one of
its items to a String.

Rob

 

[Roedy Green]

ventually found a full explanation of Generics
here:

http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf

you would have found it even more quickly by looking up "generics" in
the Java glossary at http://mindprod.com/jgloss/generics.html

 

[Neal Gafter]

Not sure I agree with the decisions on generics; since they had
already encountered the issues with arrays, why go for a different
solution with generics? I'd happily take the risk of getting a
runtime exception if I was stupid enough to cast an ArrayList<Integer>
to List<Object> and try to add a String; after all that's exactly what
happens if I cast an Integer[] to an Object[] and try to set one of
its items to a String.

Unfortunately that solution doesn't work with generics. Generics are
implemented using erasure - as they must be in order to allow existing bytecode
to interoperate with code generated by a generics-supporting version of javac -
which means there isn't enough information available at runtime to do the
equivalent of an array store exception.

 

[Neal Gafter]

you would have found it even more quickly by looking up "generics" in
the Java glossary at http://mindprod.com/jgloss/generics.html

Or even more quickly yet by doing a google search for "java generics". The
tutorial is the first or second hit.

 

[Robert Elliot]

Roedy Green wrote:

Or even more quickly yet by doing a google search for "java generics". The
tutorial is the first or second hit.

I looked on the glossary page before posting; it didn't feature on the
index page, and searching around on eg the Gotchas page I found the
majority of the Applets didn't work on my browsers (tried it with IE
and Firefox), so I rather gave up on it. Just looked again;
unfortunately on Firefox the "Google" image obscures the bit that
makes it clear that the glossary contains much more than the index
items. I'd done rather a lot of searches on Google too, and gone
through the Sun site in search of some details; funny how sometimes
you miss the most obvious search term.

Rob

 

[Robert Elliot]

Not sure I agree with the decisions on generics; since they had
already encountered the issues with arrays, why go for a different
solution with generics? I'd happily take the risk of getting a
runtime exception if I was stupid enough to cast an ArrayList<Integer>
to List<Object> and try to add a String; after all that's exactly what
happens if I cast an Integer[] to an Object[] and try to set one of
its items to a String.

Unfortunately that solution doesn't work with generics. Generics are
implemented using erasure - as they must be in order to allow existing bytecode
to interoperate with code generated by a generics-supporting version of javac -
which means there isn't enough information available at runtime to do the
equivalent of an array store exception.

Thanks for the explanation - so since it's just a pre 1.5 List as
compiled code there would be no way to check whether what is being put
in is safe or not.

Presumably that also means that it is still possible to end up with an
incorrect type in a theoretically type safe Collection at runtime if
you ignore an "unchecked" warning at compile time. Not sure I've got
my head round the implications fully yet - need to think about it some
more. Cheers for the help.

Rob

 

[Roedy Green]

I looked on the glossary page before posting; it didn't feature on the
index page,

If you had looked up "generics" under G, at the bottom of the page it
would have taken you to that tutorial you found so useful.

 

[Neal Gafter]

Presumably that also means that it is still possible to end up with an
incorrect type in a theoretically type safe Collection at runtime if
you ignore an "unchecked" warning at compile time. Not sure I've got
my head round the implications fully yet - need to think about it some
more.

That's correct. If you don't like that and don't mind paying the overhead of
the checking, consider using the new checked collection wrappers in
java.util.Collections.

 

[Robert Elliot]

That's correct. If you don't like that and don't mind paying the overhead of
the checking, consider using the new checked collection wrappers in
java.util.Collections.

Thanks for the pointer, I'm still playing with 1.5 and hadn't noticed
these new wrappers in the Collections class. Will go and explore.

I don't mind it - after all, it's not as if you often (ever?) actually
get issues due to non type safe Collections in Java 1.4 or previous.
I only really wanted Generics because I'm writing an API and wanted to
make absolutely transparent to a potential user what they would
actually be getting in a List retrieved by a call to one of the API's
methods.

Cheers,
Rob