0

I've got question about java's equals(Object o) and hashCode() methods. What are the technical constraints of implementation this both methods? Is there something that I can't do during implement this methods?

Mirek
  • 391
  • 3
  • 8
  • 20
  • 3
    What specifically do you mean by technical constraints? – ekatz Sep 21 '11 at 21:45
  • Like what? You can implement them however you want. If you implement them *poorly*, you may be in for a bad day, but that's a different issue. What type of constraints are you envisioning? – Dave Newton Sep 21 '11 at 21:46
  • IN short, if you override one you must override the other. [Here's a detailed explanation.][1] [1]: http://stackoverflow.com/questions/27581/overriding-equals-and-hashcode-in-java – RHT Sep 21 '11 at 21:46
  • 1
    Did you mean something like "consistent with equals"? http://stackoverflow.com/questions/410236/how-to-ensure-hashcode-is-consistent-with-equals – Michael M. Sep 21 '11 at 21:52

5 Answers5

1

None. It's just two methods in Object class. You could even change an object's state within this methods and this will freak out every developer and system but it's still valid from technical point of view.

the.malkolm
  • 2,391
  • 16
  • 16
  • So: - if I override equals I must also override hashCode() - in hashCode() no dependency on data which are changeable in time - I think, also hashCode must be in the limit of Integer What else do you think about that friends? This is the question which someone asked me and I'm wondering about the answer – Mirek Sep 21 '11 at 22:06
  • You don't **have to** override them both. You can override only one of them. The code will compile. So from technical point of view it's fine. The part about not breaking contract between these methods is another question, isn't it? – the.malkolm Sep 21 '11 at 22:13
1

You can technically anything inside them you can do in any other methods.

Instead what you concern yourself with are the practical and contractual obligations of the methods.

Good rules of thumb:

  1. If you override one, override the other.
  2. Variables used in one should be used in the other.
corsiKa
  • 81,495
  • 25
  • 153
  • 204
0

a given object must consistently report the same hash value two objects which equals() says are equal must report the same hash value - so no timestamps in the hashcode :).

Two unequal objects can also have the same hashcode, though it is better to make the hashcode difficult to repoduce.

joe
  • 1
0

All you need to remember, is:

  1. those constrains are very important
  2. all are very well documented in javadoc for Object.hashCode() and Object.equals()

Make sure you understand it every time you override any of those methods.

Michał Šrajer
  • 30,364
  • 7
  • 62
  • 85
0

Is there something that I can't do during implement this methods?

Well, as a rule of thumb (and as already @RHT mentioned above and @Antti Sykäri explains here) do your future self a favor and always use EqualsBuilder and HashCodeBuilder from the Apache Commons Lang library. Because, quite frankly, at least in my case I never get to remember all the nitty-gritty details that a correct implementation would require. ;-)

Community
  • 1
  • 1
Rafael Cordones
  • 831
  • 1
  • 7
  • 8
  • I am not sure if that would be favor or dis-favor (pun intended) , while I am a big fan of Commons I do not think they are keeping up and see them moving towards Attic . 3 years ago I would have agreed 100% but now 50/50 . – Shahzeb Sep 21 '11 at 22:11
  • 1
    In case you are interested about contract between these methods you can read [here](http://www.ibm.com/developerworks/java/library/j-jtp05273/index.html) – the.malkolm Sep 21 '11 at 22:14