This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Changing the return type of a method causes a runtime failure  RSS feed

 
Anupam Bhatt
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Original Scenario:



I change it to :



This does not fail at compile time, but at runtime i get "NoSuchMethodError".

I am not clear on, why does it fail if i do not catch a return value from a method. Is it mandatory to catch a return value, if the method being called returns some value ?

I could not find any such information in the VM spec also.

Any help, pointers to the some documentation which talks about this would be highly appreciated.

Thanks,
Anupam
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Is it mandatory to catch a return value, if the method being called returns some value ?

No. What you've written is valid.
 
Prabhu Venkatachalam
Ranch Hand
Posts: 502
Java jQuery Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Code is valid.

I guess "NoSuchMethodError" is because of some other reason. can you post full class code, so that Ranchers can try to help you out.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The return type of a method is part of its "signature" -- the identifier used by callers of a method to locate the code at runtime. If you change the return type, the signature changes, and all the callers of that method must be recompiled so they use the new signature. In other words, you're getting the error because you've neglected to recompile the class in which methodA appears.
 
Anupam Bhatt
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
The return type of a method is part of its "signature" -- the identifier used by callers of a method to locate the code at runtime. If you change the return type, the signature changes, and all the callers of that method must be recompiled so they use the new signature. In other words, you're getting the error because you've neglected to recompile the class in which methodA appears.


Thanks Ernest, precisely that was the reason. The class which was making this method call was not compiled, i compiled it and it went away.

Thanks a ton for this.
 
Anupam Bhatt
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
However, the JVM spec talk about what a method signature is, and here i quote

"2.10.2 Method Signature
The signature of a method consists of the name of the method and the number and type of formal parameters (�2.10.1) of the method. A class may not declare two methods with the same signature."

I guess, either this documentation is missing the "return type" being included in the signature, Or i am missing something in the concept.
Link to the spec http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#34442
Comments?
[ June 21, 2007: Message edited by: Anupam Bhatt ]
 
Bill Cruise
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're not missing anything. The return type isn't part of the signature. If I try to declare

public int myMethod(int a){...}

public double myMethod(int a){...}

in the same class it is a compile error. The reason is that you can't rely on the return type to determine which method I meant to call at runtime.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The confusion is my fault. I used the informal term "signature", but I really should have used the more formal term method descriptor. It's the "method descriptor" for a called method that is stored in the client class files. A method descriptor is a String including a pair of parentheses containing descriptions of a method's arguments, followed by a description of its return type. In the present example, the original method's descriptor is "()V", while the revised method's descriptor is "()LMyClass;" .

The signature of a method isn't anything as concrete as a String; it's just a concept.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The confusion is EFH's fault , but you can also blame Sun for things like the javap tool. When you give the command

it gives output like

which erroneously implies that the return type is part of the "signature". (In my code, the return type was a String.) So you can't always trust Sun's tools to use terminology consistent with Sun's documentation.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In case it's not clear from Jim's post, javap is actually showing the method descriptors, but calling them "signatures."
 
Anupam Bhatt
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Perfect,

Thanks Bill and Ernest for clearing this out.
 
Anupam Bhatt
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
In case it's not clear from Jim's post, javap is actually showing the method descriptors, but calling them "signatures."


Yeah i could understand that thanks again!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!