• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Use Case where hashCode() is required & not equals()

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy!

Could there be practical use cases where you may want to override only hashCode() & not equals() ?

Thanks.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Could there be practical use cases where you may want to override only hashCode() & not equals() ?


I do not think so. The Java 5 API states for hashCode:

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.



Consider:


Suppose we have two Derived objects d1 and d2. d1.x and d2.x are both 0, but d1.y is 1 are d2.y is 2. So, d1.equals(d2) is true, but d1.hashCode() is 1 and d2.hashCode() is 2. Therefore, even though the objects are equal according to the equals(Object) method, calling the hashCode method on each of them produces a different integer result. This breaks the hashCode contract.

[ May 13, 2008: Message edited by: Eugene Wee ]
[ May 13, 2008: Message edited by: Eugene Wee ]
 
Robin Sharma
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene, thanks for the reply.

Now, i do understand the contract laid out for equals()/hashCode(). But, what if, and i'm just thinking aloud here, you required a 'write-only' data structure (say, a map), where you only wanted efficient distribution of objects into buckets without worrying about reading them back. Would you still need equals() here? A properly implemented hashCode() would be sufficient, i guess. I may be wrong here, but wouldn't write-only structures require something like this? Another area I could think of is Serialization which just requires identity hashCode.

Thanks.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

efficient distribution of objects into buckets without worrying about reading them back.



What good would that be? Correct operation of a Map requires hashCode() and equals() methods as per the API cited by Eugene.

Bill
 
Wanderer
Posts: 18671
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hash-codes are used for efficient search and retrieval, so a read-only implementation use case is pretty rare if not non-existent.

The identity hash code is not part of the object per se, but a method to generate the original hash-code of the object, if overridden. So I guess it does not fit into context.

Can you give some more cases which you have thought of? so we can throw more light on this.

Originally posted by Robin Sharma:
Eugene, thanks for the reply.

Now, i do understand the contract laid out for equals()/hashCode(). But, what if, and i'm just thinking aloud here, you required a 'write-only' data structure (say, a map), where you only wanted efficient distribution of objects into buckets without worrying about reading them back. Would you still need equals() here? A properly implemented hashCode() would be sufficient, i guess. I may be wrong here, but wouldn't write-only structures require something like this? Another area I could think of is Serialization which just requires identity hashCode.

Thanks.

 
It's just a flesh wound! Or a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic