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.

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.

So, I was wrong at overloading part But, I'm still not convinced for overriding part. Even if syntactically it is allowed, what purpose would it serve? Anyway, the actual concrete implementation would be at class level (which will implement at least one interface of that hierarchy). And at class level, does it matter that it is implementing method of which interface?
e.g.

Like I said, it's "actually only done to specify more constraints in Javadoc". For example, Collection.add only specifies that it should return true if the collection is modified. Set.add adds the constraint that any element can only be present once, and that the method should return false and not add the element if it is already a member of the collection. List.add in turn adds the constraint that the element should be added at the end and the method should always return true.

You're right that syntactically there is no benefit of overriding methods in interfaces. Semantics are just as important though.

Overriding interface methods can do more than just modify the JavaDoc. They can also change the throws list, throwing fewer checked exceptions if desired. And since JDK 5 they've been able to specify a different return type - as long as the new type is a subtype of the original type.

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.

But then why do the java docs don't mention that List.add(E)overridesCollection.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.

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

Mansukhdeep Thind wrote:But then why do the java docs don't mention that List.add(E)overridesCollection.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.

I think Rob already explained that with his example of Collection.add() and Set.add(). It is used to update the documentation, and specifically to add constraints to the higher level definition. After all - what is an interface if not its documentation?

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here

Mansukhdeep Thind wrote: . . . But then why do the java docs don't mention that List.add(E)overridesCollection.add(E). Instead ,they mention at every place that method x in sub interface is specified by method y in the super interface. . . .

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.

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

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.

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? Specifically ,when they say:

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.

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.

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.

That's because there isn't any such rule. There is, however, a section of the Java Language Specification which says that interface types automatically have the methods toString(), equals(Object), and hashCode(), and probably all of the other methods which Object has. I don't have a link to the exact section (I'm not a frequent user of the document) but I'm sure you could find it by searching the JLS with not much trouble.

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3028

10

posted May 06, 2013 11:19:46

0

Mansukhdeep Thind wrote:

Campbell Ritchie wrote: The List#hashCode method overrides the Object#hashCode method by specifying the algorithm to be used.

Not really. The tutorial is not a good place to go for precise comprehensive defninions; 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 Lanaguage 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 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.

Technically according to the JLS, an interface does not override these, if there is no superinterface. 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.

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.

That explains it Mike. I'll try and get into the habit of looking up such stuff in the JLS myself from now on.

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.