«

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

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 wrote:
> 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>.

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

On 5 Jun 2004 11:41:49 -0700, (Robert
Elliot) wrote or quoted :

>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


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Robert Elliot wrote:
> 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.

Roedy Green wrote:
> On 5 Jun 2004 11:41:49 -0700, (Robert
> Elliot) wrote or quoted :
>
>
>>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

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

Neal Gafter <> wrote in message news:<>...
> Roedy Green wrote:

> > 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.

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

Neal Gafter <> wrote in message news:<>...
> Robert Elliot wrote:
> > 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

On 6 Jun 2004 03:49:54 -0700, (Robert
Elliot) wrote or quoted :

>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.



--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Robert Elliot wrote:
> 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.