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.
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
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.
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.