4

In Hibernate documentation in chapter 4.3. "Implementing equals() and hashCode()" they wrote this sentence:

"Furthermore, if an instance is unsaved and currently in a Set, saving it will assign an identifier value to the object. If equals() and hashCode() are based on the identifier value, the hash code would change, breaking the contract of the Set."

I don't understand what contract it breaks and what problems can arrive from it.

marianomdq
  • 399
  • 3
  • 14
Daniel
  • 417
  • 1
  • 7
  • 14
  • 2
    http://stackoverflow.com/questions/1928191/what-is-the-correct-way-of-overriding-hashcode-and-equals-methods-of-persis has some good answers on using _business keys_ which **should** help avoid these issues. – andyb May 01 '11 at 08:17

1 Answers1

10

a HashSet (backed by HashMap) works if the hashcodes of objects do not change. That's because it holds them based on their hashcodes.

Thus, if you base your hashCode() on the identifier, and put entities without identifier, they will all have the same hash code. Which, if they are also equal(..) (which they will be), will not allow more than one object in the set.

Now, if the set has some entities with assigned identifier and one without, which is later saved, then the set will have the wrong hashcode for it.

Also check this question for what are your options about hashCode() and equals(..)

Community
  • 1
  • 1
Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140