aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Method Signature Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Method Signature" Watch "Method Signature" New topic
Author

Method Signature

Salim Mohamed
Ranch Hand

Joined: Sep 19, 2002
Posts: 55
What is method signature ? does it include the 1.return type , 2.name of method and 3.the parameters or only a combination of the 3 ? What does java compiler checks to make sure that a sub class has overrided the super class methods ? Can anyone explain. Thanks in advance.
Manish Hatwalne
Ranch Hand

Joined: Sep 22, 2001
Posts: 2578

AFAIK, the method signature contains methods name and its parameters list with their type but not the return type. Correct me if I am wrong...
- Manish
Todd Killingsworth
Greenhorn

Joined: Jan 30, 2002
Posts: 28
1) From the JLS:
8.4.2 Method Signature
The signature of a method consists of the name of the method and the number and types of formal parameters to the method.
2) For a successful override, Java requires both the method signature and the return type to be exactly the same. Changing the signature will cause overloading, not overriding. A change in the return type only will cause a compiler error. It breaks overloading because its not exactly the same as a method in the parent class, yet it's not enough for successful overloading - a change in the signature is required.
HTH,
Todd
ramki srini
Greenhorn

Joined: Aug 27, 2002
Posts: 26
A subclass may override non-static methods inherited from the superclass, noting the
following aspects:
(a) A new method definition MUST have the SAME method signature ( method name and parameters types not essential the parameters name) and the SAME return type.
(b) The new method definition, in addition, CANNOT 'NARROW' the accessibility of the method, but it can 'WIDEN' it, i.e. can™t replace with weaker access privileges.
(c) The new method definition in the subclass can only specify all or a subset of the exception classes (including their subclasses) specified in the throws clause of the overridden method in the superclass.
(d) Whether the parameters in the overriding method should be final is at the discretion
of the subclass. A method's signature does not encompass the final modifier of parameters, only their types and order.
(e) An overridden method and a method in the superclass may declare their methods synchronized independently of one other.
Jay Ashar
Ranch Hand

Joined: Oct 13, 2002
Posts: 208
Question>
If there is a method in class which do not throw an exception, can this method throw exception when subclass overrides this method??


SCJP 1.4<br />SCWCD 1.3
Ron Newman
Ranch Hand

Joined: Jun 06, 2002
Posts: 1056
No, if the method you are overriding does not throw checked exceptions, you can't throw them either.
You can, however, throw unchecked exceptions (RuntimeException and its subclasses).


Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Originally posted by Hetal Mehta:
Question>
If there is a method in class which do not throw an exception, can this method throw exception when subclass overrides this method??

Howdy -- as Ron said, you cannot throw a checked exception from an overriding method unless the overridden method declares that exception (or declares a supertype of the exception).
Just a couple more points:
* This applies to implementing methods from an interface or abstract class as well (all rules of legal overriding are identical for both overriding methods and implementing abstract methods)
* Although I know this one is so obvious, but some folks do ask... the *reverse* is not true. In other words, if the method you are implementing/overriding declares a checked exception, the implementing/overriding method does NOT need to declare the exception unless it, too, throws it. So just because the method you're implementing/overriding does something risky (or declares that it might), does not mean YOU have to. You might just have a better, safer way to do the work.
Of course, if the abstract and/or superclass method you're overriding did not take into account that YOU might need to do something with potential exceptions, then you are -- to put it politely -- *screwed*. Which brings up the whole issue of what kinds of exceptions you should declare in an interface. If you do NOT declare exceptions, you are limiting what your implementers can do. If you DO declare exceptions in your interface methods, you are not forcing the implementers to declare them/ throw them, etc. but you *are* giving them the flexibility.
Just some thoughts...
cheers,
Kathy (throwing an insufficientCaffeineException this morning)


Co-Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007124/ref=jranch-20" target="_blank" rel="nofollow">"Head First Design Patterns"</a><br /> <br />Just a Jini girl living in a J2EE world.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Method Signature
 
Similar Threads
Error running program in Windows.
Method Signature
Abstract methods cannot be final!!!!Really??
doPost query
Not able to Call The Action class