Generics method overloading

[ravisha andar]

How does the below code complie when return type does not matter for method overloading

void m1(List<String> str)
{

}

String m1(List<Integer> str)
{
return "";
}

Please help me understand this.

[Stephan van Hulst]

I think you are mistaken. This doesn't compile.

[Winston Gutkowski]

Stephan van Hulst wrote:I think you are mistaken. This doesn't compile.

Actually, it does on my machine.

ravisha andar wrote:How does the below code complie when return type does not matter for method overloading

What makes you think it wouldn't...or are you referring to method overriding?

List<String> and List<Integer> are not related, except in the fact that they are Lists, so the compiler happily accepts your two methods as different signatures.

Winston

[Edit] Actually, that last statement is wrong. The compiler plainly does take return type into account when determining signature, because if you change that first method to return a String, then it won't compile.

[Stephan van Hulst]

What the... I just compiled using void the first time, I missed the String return type. It actually makes a difference?

Is this an oversight in the compiler, or does the JLS actually have anything to say about return types in combination with type erasure? I can't imagine the designers intended this to be legal.

[Winston Gutkowski]

Stephan van Hulst wrote:What the... I just compiled using void the first time, I missed the String return type. It actually makes a difference?

Is this an oversight in the compiler, or does the JLS actually have anything to say about return types in combination with type erasure? I can't imagine the designers intended this to be legal.

I dunno, but I suspect it may have something to do with the fact that List<Integer> and List<String> can't possibly be the same type (although I understand that after erasure they are) - in fact, they're not even related as far as generics is concerned.

Fun stuff though, and I agree it's not entirely consistent. Just can't be fagged to dredge through the JLS on a Sunday....

Winston

[Jeff Verdegan]

That's gotta be a bug.

[Rob Spoor]

Not necessarily. The method signatures of the two in native code are m1(Ljava.util.List;)V and m1(Ljava.util.List;)Ljava.lang.String; - different enough for the JVM to tell the two apart.

I have just tried it. The Java 6 compiler allows this code, the Java 7 compiler doesn't. Apparently it was a bug that's been fixed in Java 7.

[Jeff Verdegan]

Rob Spoor wrote:Not necessarily. The method signatures of the two in native code are m1(Ljava.util.List;)V and m1(Ljava.util.List;)Ljava.lang.String; - different enough for the JVM to tell the two apart.

Except that return type is not part of a method's signature. I'm gonna go with bug in the compiler.

I have just tried it. The Java 6 compiler allows this code, the Java 7 compiler doesn't. Apparently it was a bug that's been fixed in Java 7.

My IntelliJ also complained about it.

[Winston Gutkowski]

Rob Spoor wrote:Not necessarily. The method signatures of the two in native code are m1(Ljava.util.List;)V and m1(Ljava.util.List;)Ljava.lang.String; - different enough for the JVM to tell the two apart.

I guess the question is - does the compiler actually use that native code sig to determine whether there's an error? In v6 clearly not; in v7, maybe it does.

Personallly, I quite like the v6 interpretation for applicability; obviously not for consistency though.

Winston

[Rob Spoor]

Jeff Verdegan wrote:

Rob Spoor wrote:Not necessarily. The method signatures of the two in native code are m1(Ljava.util.List;)V and m1(Ljava.util.List;)Ljava.lang.String; - different enough for the JVM to tell the two apart.

Except that return type is not part of a method's signature.

It is in JNI.