This discussion is archived
1 2 Previous Next 15 Replies Latest reply: May 19, 2010 9:42 AM by 843793 RSS

Typed collection and method overloading

843793 Newbie
Currently Being Moderated
With generics collections are now typed safe. so why following is not legal

class Test {
private void myMethod(List<Number> l) {}

private void myMethod(List<String> l) {}
}


I have 2 different flavour of method in same class with different Type of collection. I should allows to overload
  • 1. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    The problem is type erasure (google it for an extensive explanation).

    At runtime there is no information if any given List is a List<Number> or a List<String>, they are both considered to be simply "List". Therefore there's no way to distinguish those two methods at runtime.
  • 2. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    agreed that method overloading is at Object type level and I can not have 2 method with same object type in a class.
    But with generics java should allowed it. and there should be some mechanism at run time also to bound typed collection
  • 3. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    hkachoria wrote:
    But with generics java should allowed it.
    But it doesn't.

    What are you trying to say? "should" means almost nothing.
    and there should be some mechanism at run time also to bound typed collection
    What do you mean by "bound"?
  • 4. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    OK I should improve my should :)
    With generics I thought that I can have overloading with different type of collection and based on the type I can have return type (same type)
    so when I start writing this compiler complain about this.

    Bound means in my word, if I have typed collection then collection is bound to accept object of that particular type. It’s same as any declaration.
    As per Java doc "Overloaded methods are differentiated by the number and the type of the arguments passed into the method"

    And we have collection of different types then why I'm not allowed to overload a collection with different types.
    I hope I'm quite reasonable :)
  • 5. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    hkachoria wrote:
    With generics I thought that I can have overloading with different type of collection
    Which turned out to be false.
    and based on the type I can have return type (same type)
    You can have the return type depend on the argument type by using a type parameter on your method, but that only works with a single method.
    so when I start writing this compiler complain about this.
    Because it doesn't work as you thought it would.
    Bound means in my word, if I have typed collection then collection is bound to accept object of that particular type. It&#146;s same as any declaration.
    You can use the Collections.checked*() methods to produce a collection that actually does the type checks at runtime, if you whish.
    As per Java doc "Overloaded methods are differentiated by the number and the type of the arguments passed into the method"
    That's from one of the very first tutorials and therefore somehow oversimplifies things (which is necessary in order to not crush beginners with tons of technical jargon and details).

    Read what [the JLS has to say on the topic of method signatures|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#38649]. Signatures are what uniquely identifies a method. Therefore you can't have to methods with the same signature or override-equivalent signatures in one class.
    And we have collection of different types then why I'm not allowed to overload a collection with different types.
    Because the signatures of your two methods are override-equivalent.
    I hope I'm quite reasonable :)
    I don't know, exactly. The idea that this could work is reasonable. But I told you that it doesn't work. If you still insist that it works or that it must work, then that's being unreasonable.
  • 6. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    OK :)
    I will not insist but do you know why during design of generics this idea was not considered?
  • 7. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    hkachoria wrote:
    do you know why during design of generics this idea was not considered?
    I'm very, very sure that it was considered, they considered a lot of things when designing generics.

    The reason why type erasure was chosen as the way to implement generics (which directly results in the restriction you see now) is that it was the most viable solution that provided very, very good backwards-compatibility both on the binary level (.class files both with and without generics can be mixed) and at the source files (old code could incrementally be enhanced with generics). Java has traditionally had a very strong focus on backwards-compatibility and any solution that didn't provide that wouldn't have bee accepted by a big part of the community.

    Compare that with the way generics are implemented in C#, where a List[Foo] is a very different type than a List. They broke backwards compatibility (which is not necessarily a bad thing, it just shows that they had different design goals) and therefore could implement a more powerful version of that concept. For example .NET supports value-types (primitive types would be the closes equivalent in Java, but that's only telling halve the story) as type parameters and actually produces specialized code that can optimize on that fact.
  • 8. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    Thanks, so I can say everything should not be served in one plate it's step by step :) (may be we can have this feature in future......)
    Thanks for your answer
  • 9. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    hkachoria wrote:
    (may be we can have this feature in future......)
    There are some small steps in the direction. If you're interested in it, the you should google for "reified generics java".

    It's definitely not in Java 7, however.
  • 10. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    Joachim, hope you have a good answer for this because it drives me crazy:

    I have the following:
    public class MenuPage
        private OrderableIngredient getIngredientFromLookup(ArrayList<OrderableIngredient> items, String key){
         ...
        }
    
        private OrderedIngredient getIngredientFromLookup(ArrayList<OrderedIngredient> items, String key){
         ...
        }
    }
    So what's that? I think nothing extremely different than the initial poster's example; only names change and the return types, which -as far as I know- are not used in method calling on runtime. The problem with this is that actually IT WORKS!!! Netbeans complains about it but java compiler has no problem. What is going on here? Do I miss something? Does the return type make some difference? Every suggestion is wellcomed.

    Oh and by the way plz don't ask me for SSCCE since this is company code in a huge project. Thanks in advance.
  • 11. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    Hello Starfighter,

    as Joachim correctly pointed out, this is a consequence of Type Erasure. However, since Java has single dispatch it has little to do with runtime type representation/reification. When you call a method such as getIngredientFromLookup it gets compiled down to an invokevirtual instruction which (among other things) takes

    - a name,
    - an owner type (MenuPage) and
    - a signature/descriptor ([§4.3.3 JVMS|http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#7035])

    The owner type must/can only declare one method with a given name and descriptor.

    Now, here are the two descriptors for getIngredientFromLookup:
    (Ljava/util/ArrayList;Ljava/lang/String;)OrderableIngredient
    (Ljava/util/ArrayList;Ljava/lang/String;)OrderedIngredient
    Do you see the difference?

    With kind regards
    Ben
  • 12. Re: Typed collection and method overloading
    EJP Guru
    Currently Being Moderated
    I keep reading that the return type isn't part of the method signature for the purpose of method resolution in the compiler. It turns out that that isn't true for abstract methods or generic methods (JLS #15.12.2.5-6).
  • 13. Re: Typed collection and method overloading
    843793 Newbie
    Currently Being Moderated
    Greetings Ben,

    Thanks for answering that. This was my initial suspicion. But I see there a problem: Supposing that I do the following
    Object obj = getIngredientFromLookup(someKindOfArray, "a string");
    or
    getIngredientFromLookup(someKindOfArray, "a string");
    According to §4.3.3 JVMS this should give an error, since the compiler doesn't know which method to call. Or call one of the "overloads" by chance. This behavior doesn't seem to be right to me.

    Anyway thanks again.
  • 14. Re: Typed collection and method overloading
    EJP Guru
    Currently Being Moderated
    According to §4.3.3 JVMS this should give an error
    §4.3.3 JVMS doesn't say any such thing, or indeed anything about compile errors.

    The methods don't erase to the same signature because the return types are different, so the declarations are legal.
    since the compiler doesn't know which method to call.
    Yes it does. The compiler arranges to calls the most specific method [JLS #15.12.2.5|http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.12.2.5]
    Or call one of the "overloads" by chance. This behavior doesn't seem to be right to me.
    It isn't.

    What you are missing here is that the compiler can see the non-erased types in the .class file, although the JVM doesn't.
1 2 Previous Next