• 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

Can Interface methods overload and override

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can Interface methods can overload and override?
 
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

praveen kumar gowda wrote:Can Interface methods can overload and override?


No. Interface methods can be implemented. To overload/override a method, that method must be defined first. Interface do not contain method definition. It only contains method declaration.

I hope this helps.
 
Bartender
Posts: 1051
5
Hibernate Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
praveen

I can understand you getting a little confused here, especially if you take the following example.



The annotation @Override is confusing but you are not overriding methodA. Something like @Implements would have been a lot nicer but you can't have everything!
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Got it.

Thanks Rob Spoor.
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome.
 
Master Rancher
Posts: 4806
72
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


-->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.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


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
 
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

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.
 
Mansukhdeep Thind
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 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.
 
Mansukhdeep Thind
Ranch Hand
Posts: 1164
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



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.



Perhaps the jargon is generic. Thanks anyways.

 
reply
    Bookmark Topic Watch Topic
  • New Topic