• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Generics method overloading

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Saloon Keeper
Posts: 13280
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you are mistaken. This doesn't compile.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Saloon Keeper
Posts: 13280
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's gotta be a bug.
 
Marshal
Posts: 22453
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Marshal
Posts: 22453
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
This guy is skipping without a rope. At least, that's what this tiny ad said:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic