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

Discussion in 'Java' started by Robert Elliot, Jun 5, 2004.

  1. 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
     
    Robert Elliot, Jun 5, 2004
    #1
    1. Advertising

  2. Robert Elliot

    Neal Gafter Guest

    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>.
     
    Neal Gafter, Jun 5, 2004
    #2
    1. Advertising

  3. 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
     
    Robert Elliot, Jun 5, 2004
    #3
  4. Robert Elliot

    Roedy Green Guest

    Roedy Green, Jun 5, 2004
    #4
  5. Robert Elliot

    Neal Gafter Guest

    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.
     
    Neal Gafter, Jun 5, 2004
    #5
  6. Robert Elliot

    Neal Gafter Guest

    Neal Gafter, Jun 5, 2004
    #6
  7. 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
     
    Robert Elliot, Jun 6, 2004
    #7
  8. 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
     
    Robert Elliot, Jun 6, 2004
    #8
  9. Robert Elliot

    Roedy Green Guest

    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.
     
    Roedy Green, Jun 6, 2004
    #9
  10. Robert Elliot

    Neal Gafter Guest

    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.
     
    Neal Gafter, Jun 6, 2004
    #10
  11. Neal Gafter <> wrote in message news:<>...
    > 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.


    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
     
    Robert Elliot, Jun 6, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Webb  Roberts

    Generics? Covariant return types?

    Webb Roberts, Nov 10, 2005, in forum: Java
    Replies:
    3
    Views:
    422
    Thomas Hawtin
    Nov 10, 2005
  2. Alex Vinokur
    Replies:
    7
    Views:
    524
    Karl Heinz Buchegger
    Apr 15, 2004
  3. Rob.
    Replies:
    9
    Views:
    409
    Alf P. Steinbach
    Jun 26, 2004
  4. Martin Stettner

    Covariant return types

    Martin Stettner, Jan 30, 2005, in forum: C++
    Replies:
    8
    Views:
    505
    Bogdan Sintoma
    Feb 1, 2005
  5. Replies:
    17
    Views:
    660
    James Kanze
    Feb 12, 2008
Loading...

Share This Page