praveen kumar gowda wrote:Can Interface methods can overload and override?
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Rob Spoor wrote:Interface methods can very much be overloaded and overridden. The overriding just must happen in another interface, and is actually only done to specify more constraints in Javadoc. An example is the add method of java.util.Set; this overrides the same method of java.util.Collection. As for overloading, check out the add methods of java.util.List.
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Rob Spoor wrote:Interface methods can very much be overloaded and overridden. The overriding just must happen in another interface, and is actually only done to specify more constraints in Javadoc. An example is the add method of java.util.Set; this overrides the same method of java.util.Collection. As for overloading, check out the add methods of java.util.List.
~ Mansukh
Mansukhdeep Thind wrote:But then why do the java docs don't mention that List.add(E) overrides Collection.add(E). Instead ,they mention at every place that method x in sub interface is specified by method y in the super interface. I agree that sub interface method behavior is a special case of its super interface method behavior. But to say that methods in an interface can be overridden sounds a bit odd to me. Like Anayonkar said, you can't possible override something that doesn't exist yet.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
There is no behaviour to override in the Collection#add method, so they say specified instead. Jargon is very useful, but you do have to learn what it means.Mansukhdeep Thind wrote: . . . But then why do the java docs don't mention that List.add(E) overrides Collection.add(E). Instead ,they mention at every place that method x in sub interface is specified by method y in the super interface. . . .
The equals() method adds a constraint to the general contract for equals(): that both objects are Lists. So this should print true:-The List#hashCode method overrides the Object#hashCode method by specifying the algorithm to be used.-->Oddly, it also struck me that many interfaces in java override equals() and hashCode() methods of Object. For example, the List interface. It has overridden versions of these two methods of Object class as per the docs. When we override a method, that means we define it in a more specific manner as compared to its super class. Also, interfaces in java aren't supposed to contain any method definitions. Neither can interfaces inherit from a class. How are these two methods present in the List interface in the first place? These don't make sense together.
Campbell Ritchie wrote: The List#hashCode method overrides the Object#hashCode method by specifying the algorithm to be used.
An instance method in a subclass with the same signature (name, plus the number and the type of its parameters) and return type as an instance method in the superclass overrides the superclass's method.
~ Mansukh
Mansukhdeep Thind wrote:How is it possible for an interface to inherit an method from the root class Object when it is a rule that interfaces do not inherit from any other entity but another interface.
Mansukhdeep Thind wrote:
Campbell Ritchie wrote: The List#hashCode method overrides the Object#hashCode method by specifying the algorithm to be used.
But isn't the very definition of method overriding as specified here?
An instance method m1 declared in an interface I overrides another instance method, m2, declared in interface J iff both of the following are true:
I is a subinterface of J.
The signature of m1 is a subsignature (§8.4.2) of the signature of m2.
Mansukhdeep Thind wrote:
My doubt is still unanswered. How is it possible for an interface to inherit an method from the root class Object when it is a rule that interfaces do not inherit from any other entity but another interface. List is not a sub class of Object. In fact, it is not a class at all. Where does that equals() method come from? Or am I over-thinking this as its a matter of the jargon? Technically it sounds paradoxical that an interface overrides a method inherited from a class.
Mike Simmons wrote:
Mansukhdeep Thind wrote:
Campbell Ritchie wrote: The List#hashCode method overrides the Object#hashCode method by specifying the algorithm to be used.
But isn't the very definition of method overriding as specified here?
Not really. The tutorial is not a good place to go for precise comprehensive defninitions; they often oversimplify. In this case, they're not wrong, but they simply do not include any mention of how this concept works in abstract classes or interfaces. They're only talking about classes here. But if we go to the Java Language Specification, we can find JLS 9.4.1.1 which does deal with this case:
An instance method m1 declared in an interface I overrides another instance method, m2, declared in interface J iff both of the following are true:
I is a sub-interface of J.
The signature of m1 is a sub signature (§8.4.2) of the signature of m2.
Mike Simmons wrote:
Mansukhdeep Thind wrote:
My doubt is still unanswered. How is it possible for an interface to inherit an method from the root class Object when it is a rule that interfaces do not inherit from any other entity but another interface. List is not a sub class of Object. In fact, it is not a class at all. Where does that equals() method come from? Or am I over-thinking this as its a matter of the jargon? Technically it sounds paradoxical that an interface overrides a method inherited from a class.
Technically according to the JLS, an interface does not override these, if there is no super interface. Instead it's covered by JLS 9.2. Which leads to pretty much the same behavior that folks here have been explaining to, except the word "override" is not used.
Personally I don't see much value in the distinction between "override" and "implement", as there are some corner cases where this terminology breaks down. This is one. And nowadays the @Override annotation is used in some places that are not technically overriding, according to the original definitions. But so what? The rules are essentially the same: if you have a type with a method with the same name and argument types as an inherited method declaration (from a parent class or parent interface or from Object, whether it's abstract or not), then it's an override equivalent method, and you need to follow the rules for that.
~ Mansukh