Even in write-only mode (pretending for a moment that this might be useful for anything), if you insert a new entry and the (hash % tableSize) is the same as for another entry (it falls in the same bucket), then the hash table needs to use equals() to
test whether you've actually got the
same key as the existing key (meaning you're
replacing the previous value) or you've got a new, different key. So even a write-only table needs equals(), at least sometimes.
One reason to override hashCode() but not equals() might be to correct a defect in an existing class. Perhaps you have a class written by someone else, where they overrode equals() but forgot to override hashCode(). In some cases you might not be able to modify the source of that class, but can create a better class by extending it and providing a better hashCode(). So really, both methods are being overridden by
someone, but
you are only overriding one of them.
Another possibility is that you can create a
legal but
inefficient hashCode() method such as this:
This will always obey the contract of hashCode(), even if you don't override equals(). It will lead to very poor performance of any HashMap you put it in, but the HashMap should still work. Why would you ever want to do this? Well, the best reason I can think of is that you might need to test a HashMap or similar hashtable-like class, to make sure it works correctly even when hashcodes are identical. Or to test certain worst-case performance characteristics of the class. Or for teaching purposes, to show what would happen.
I don't think there is ever any reason to override hashCode() without equals() in a good, well-designed system in production (as opposed to testing).