Why does the Collection interface have equals () and hashCode ()?

Question

Why does the Collection interface have equals(Object o) and hashCode() , given that any implementation will have a default (inherited from Object )?

Answer 1

From Collection JavaDoc :

While the Collection interface does not add any conditions to the general contract for Object.equals , programmers who implement the Collection interface “directly” (in other words, create a class that is Collection , but not Set or List ) should be careful if they select override Object.equals . This is not necessary, and the easiest way to do this is to rely on but the developer may wish to implement a “value” comparison “instead of the default comparison.” ( List and Set interfaces perform such comparisons of values.)

The general contract for the Object.equals method states that equal must be symmetric (in other words, a.equals(b) if and only if b.equals(a) ). The contracts for List.equals and Set.equals show that lists are equal only to other lists and are assigned to other sets. Thus, the custom equals method for a collection class that implements neither the List and Set interface should return false when this collection is compared to any list or set. (By the same logic, it is impossible to write a class that correctly implements both Set and List interfaces.)

and

While the Collection interface does not add any clauses to the general contract for the Object.hashCode method, programmers should note that any class that overrides the Object.equals method Object.equals also override the Object.hashCode method to satisfy the general contract for the method Object.hashCode . In particular, c1.equals(c2) implies that c1.hashCode()==c2.hashCode() .

Answer 2

To answer your specific question: why does it have these methods? It is just for convenience to enable Java Docs, giving hints as to what developers should do with these methods (e.g. comparing equality of values ​​rather than references).

Answer 3

To add great answers to others. In the Collections interface, this interface defines the equals method to make some decisions about how equal two instances of the collection should work. From the JAVA 8 documentation :

In a more general case, implementations of the various interfaces of the Collection Framework can freely use the specified behavior of the underlying Object methods, if the developer considers it appropriate.

This way, you are not adding methods from the Object class for any other reason that makes the Java document more specific. That is why you do not take these methods into account in abstract methods in abstract interface methods.

In addition, in JAVA 8, according to the same reasoning scheme, the default methods from the Object class are not allowed and will generate a compilation error. I believe this was done to prevent this type of confusion. So if you try to create a default hashCode () method, for example, it will not compile.

Here is a more detailed explanation of this behavior in the JAVA 8 of the Lambda FAQ :

An interface cannot provide a default implementation for any of the methods of the Object class. This is a consequence of the "win class" rule for method resolution: a method found in a chain of superclasses always takes precedence over any default methods that appear in any superinterface. In particular, this means that you cannot provide a default implementation for equals, hashCode or toString from an interface.

This seems strange at first, given that some interfaces actually define the behavior of peers in the documentation. The List interface is an example. So why not allow it?

One reason is that it becomes harder to talk about when the default method is called. The current rules are simple: if a class implements a method, it always defeats the default implementation. Since all instances of interfaces are subclasses of Object, all instances of interfaces already have implementations other than the default: equals, hashCode, and toString. Therefore, their default version on the interface is always useless and may not compile.

Another reason is that providing the default implementation of these methods in an interface is most likely a mistake. These methods perform calculations based on the state of objects, but the interface, as a rule, does not have access to state; only the implementing class has access to this state. Therefore, the class itself must provide implementations, and the default methods are unlikely to be useful.

Answer 4

The equals method and hashCode help compare objects. The collection interface works with various objects to compare them or check for duplicates and use a hash code.

Equal & Hashable are two default contracts / rules. With this, it is assumed that equals and hashCode for this class are implemented correctly for this class.