2

I came across fact that Collection interface has methods equals and hashCode which are also contained in Object. Same is the case with List interface. I was having following doubts:

  1. Why interfaces should have these methods? Is it only because they have different meaning than those in Object ?

  2. According to this question, including these methods does not enforce the implementing class to provide their implementation as these implementations are already provided and inherited from Object. So technically including them in the interfaces does not have any effect. This again underlines importance of first doubt, why interfaces need to have these methods?

    This page says:

    These methods perform computations over the object’s state, but the interface, in general, has no access to state; only the implementing class has access to this state.

    Which I feel further increases importance of first question.

  3. If we at all need them in interfaces, then why Java framework dont have super-interface containing them and have such interfaces implement this interface, just like as all classes are subclasses of Object?

Andy Turner
  • 137,514
  • 11
  • 162
  • 243
MsA
  • 2,599
  • 3
  • 22
  • 47
  • This is covered in the Java Language Specification. All objects inherit from `Object`, so all implementors of interfaces must have those methods. Implicitly, objects of an interface type must have them. In order to call them the interface calls must compile. In order to compile they must somehow exist in the interface. You can guess the rest of the rationale. – Lew Bloch Mar 22 '20 at 20:19

1 Answers1

5

The List interface declares equals and hashCode so that it can document extra constraints that the implementations must follow. For example, the List interface documentation requires that the equals method must consider two lists equal if the have the same items in the same order, no matter how the lists are implemented.

There is no way the compiler or runtime can enforce these requirements, so breaking them leads to runtime bugs that may be hard to find.

Joni
  • 108,737
  • 14
  • 143
  • 193
  • So its all about documenting some more stuff specific to those classes. That is `Object.equals()` says "Indicates whether some other **object** is "equal to" this one." Whereas `Collection.equals()` says "Compares the specified object with this *collection* for equality.". But they are not actually enforcing anything, right? I mean `Collection` has `equals(Object)`, not `equals(Collection)` – MsA Mar 22 '20 at 18:04
  • exactly, nothing stops you from implementing equals in a way that breaks the contract - you can easily break the general contract in Object and the more specific contract in List – Joni Mar 22 '20 at 18:11
  • I guess this is same as `Set` [having same methods](https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/java/util/Set.java) as `Collection`. This is why [doc](https://docs.oracle.com/javase/8/docs/api/java/util/Set.html) says "The specifications accompanying these declarations have been tailored to the Set interface, but they do not contain any additional stipulations." **Q1.** Right? **Q2.** But I dont really get whats the point in practice of extending interface and then redeclaring all its methods!!?? – MsA Mar 22 '20 at 18:22
  • Wrong guess. `Set` inherits the methods from `Collection`. As with classes interfaces can override methods. in the case of `add` there is a difference in declared exceptions. – Lew Bloch Mar 22 '20 at 20:23