How default .equals and .hashCode will work for my classes?
Solution 1
Yes, the default implementation is Object's (generally speaking; if you inherit from a class that redefined equals and/or hashCode, then you'll use that implementation instead).
From the documentation:
The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true).
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)
Solution 2
From Object
in one of the JVM implementations:
public boolean equals(Object object) {
return this == object;
}
public int hashCode() {
return VMMemoryManager.getIdentityHashCode(this);
}
In both cases it's just comparing the memory addresses of the objects in question.
Solution 3
There are default implementations of equals()
and hashCode()
in Object. If you don't provide your own implementation, those will be used. For equals()
, this means an ==
comparison: the objects will only be equal if they are exactly the same object. For hashCode()
, the Javadoc has a good explanation.
For more information, see Effective Java, Chapter 3 (pdf), item 8.
Solution 4
Yes, from Object
class since your class extends Object implicitly. equals
simply returns this == obj
. hashCode
implementation is native. Just a guess - it returns the pointer to the object.
Solution 5
If you do not provide your own implementation, one derived from Object would be used. It is OK, unless you plan to put your class instances into i.e. HashSet (any collection that actually use hashCode() ), or something that need to check object's equality (i.e. HashSet's contains() method). Otherwise it will work incorrectly, if that's what you are asking for.
It is quite easy to provide your own implementation of these methods thanks to HashCodeBuilder and EqualsBuilder from Apache Commons Lang.
alexeypro
Techie who gets things DONE. Interested in technology, startups, entrepreneurship, web, software and working out.
Updated on September 19, 2020Comments
-
alexeypro over 3 years
Say I have my own class
public class MyObj { /* ... */ }
It has some attributes and methods. It DOES NOT implement equals, DOES NOT implement hashCode.
Once we call equals and hashCode, what are the default implementations? From Object class? And what are they? How the default equals will work? How the default hashCode will work and what will return? == will just check if they reference to the same object, so it's easy, but what about equals() and hashCode() methods?
-
Jeremy over 13 yearsIt is a pointer to the object located in memory, but it's not a memory address of the object. The GC can move the object around in memory and the hash code will remain the same.
-
khachik over 13 yearsWhat version of JDK it from? In
v6u23 ea
:public native int hashCode();
-
khachik over 13 years@Jeremy Thanks. stackoverflow.com/questions/2427631/… may be interesting.
-
Brad Mace almost 13 years@kha - You're right, I think I tracked down one of the native implementations to see what it actually did
-
Basil Bourque over 12 years(a) Why do you say the Object class’ default implementation of ‘equals’ will not work correctly with HashSet? That contradicts the other answers on this page. (b) Thanks for the Commons Lang links.
-
Paweł Dyda over 12 years@Basil: I don't think that contradicts. Of course default implementation would work... somehow, but not the way you expect. That is, since equals() uses reference equality, two otherwise identical objects would be "different" in the eyes of default implementation. As the result, you might end up having two different instances of the exactly same thing in your Set. And rather typical use of Sets is when you want to eliminate duplicates...
-
supercat over 11 years@PawełDyda: The default behavior is generally correct for mutable types. If
Foo
andBar
are references to two different instances of a mutable type, and there exists a method (e.g.SomeMutatingMethod
) such thatFoo.SomeMutatingMethod()
does not affectBar
the same way it doesFoo
, that difference should be sufficient to regard the objects as unequal. -
Matthias Braun over 3 yearsMind that contrary to
hashCode
's documentation, HotSpot returns a random number per default as the hash. See also this blog entry. -
Matthias Braun over 3 years"In both cases it's just comparing the memory addresses of the objects in question.": HotSpot returns a random number per default as the hash. See also this blog entry.