• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Changing the return type of a method causes a runtime failure

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 502
jQuery Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
reply
    Bookmark Topic Watch Topic
  • New Topic