Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Generics method overloading

 
ravisha andar
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Pie
Posts: 5810
61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you are mistaken. This doesn't compile.
 
Winston Gutkowski
Bartender
Pie
Posts: 10417
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Pie
Posts: 5810
61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Pie
Posts: 10417
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's gotta be a bug.
 
Rob Spoor
Sheriff
Pie
Posts: 20527
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Pie
Posts: 10417
63
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Pie
Posts: 20527
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic