Avoid auto generate hashCode and equals when using @JvmRecord

Support
1

Why don’t we let JVM take it? I understand we need override toString() to keep consistency in Kotlin world. But for hashCode and equals?

1 Like
2

The only reason I can think of for hashCode() is to have consistent implementation across target platforms, but I don’t see why anyone would need that :wink: Probably it was not yet done.

3 Likes
3

Changing the hash implementation would be a breaking change for code which relies on binary serialization of a HashMap (and other hash dependant classes).

  1. hash map is serialized and stored in a database
  2. kotlin updated, hash codes of objects change
  3. hash map is fetched from a database and deserialized but it’s corrupted and values are inaccessible.
1 Like
4

Storing hash codes anywhere doesn’t sound like a good idea. Documentation says explicitly there are no guarantees for it to be consistent, even if using the same codebase in same versions:

This integer need not remain consistent from one execution of an application to another execution of the same application.

2 Likes
5

Yes it’s bad but I have seen things.

1 Like