equals() without hashCode()

Question

Can I only implement equals() but not hashCode() if I only need to compare objects and not yet plan to put the objects into any hash based containers?

Seems all Java bibles say these two MUST be implemented together. :(

My concerns: -If I always implement hashCode() together with equals() there will be lots of code not really used, and without unit test covering. (I'm not going to unit test hashCode() if not used) -It's only until when I put the object into a hash based container I know how the objects are intended to be looked up. And only until then I can be sure which hashing strategy to use.

Answer 1

Yes, you can only implement equals() method without implementing hashcode() method.

But standard practice says that you should implement both of them and for the equal object the hashcode should be the same.

Answer 2

You can, but you'll be breaking the general contract of equals, and this will lead to weird bugs. Even if you don't think you're using the hash codes, any external code you pass the objects to might rely on them, even if it doesn't seem to be hash-based. If you're not going to give your objects a decent hash method, at least make it throw a runtime exception. It's almost always better to give your objects a decent hashCode, though.

Answer 3

Oracle's tutorial answers this

The hashCode() Method

By definition, if two objects are equal, their hash code must also be equal. If you override the equals() method, you change the way two objects are equated and Object's implementation of hashCode() is no longer valid. Therefore, if you override the equals() method, you must also override the hashCode() method as well.

Answer 4

As long as is not mandatory to implement hashCode, whenever you implement equals, you MUST also implement hashCode

If you fail to do so, you will end up with broken objects. Why? An object’s hashCode method must take the same fields into account as its equals method. By overriding the equals method, you’re declaring some objects as equal to other objects, but the original hashCode method treats all objects as different. So you will have equal objects with different hash codes. For example, calling contains() on a HashMap will return false, even though the object has been added.

Answer 5

Yes, you can, but is it recommended ? no

What all books say, is that if equals returns true, the hashcodes MUST be identical, which will be so. But, it is best to specify it further, for your own instances, just like you do with equals.

Answer 6

Well, obviously You can, but the fact that You don't plan to use hashing is not a sufficient reason not to implement it. Some of the libraries You use could make use of hashing. If you want to avoid testing equals or hashcode, You could try auto-generating those methods (most IDEs have that feature), or use project lombok (https://projectlombok.org)