• 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

hashCode() and equals()

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have read in some tutorials that hashCode() is properly implemented only if it returns same int value for multiple invocations of hashCode() method on same object.See the code below.hashCode() has been invoked twice on the same object.When you compile and run this code you get two different values.This example is from Dan Chisholm's.its the 8th question.multiple choices are given as follows.please explain why e is the right choice.

a. return 31;
b. return getI1();
c. return getI2();
d. return getI1() + getI2();
e. return 31 * getI1() + getI2();
f. None of the above



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

Originally posted by Shweta R Dhaneshwar:
I have read in some tutorials that hashCode() is properly implemented only if it returns same int value for multiple invocations of hashCode() method on same object...



My understanding is, when you say same object, the state of the object should not be changed(state here is the values of its member variables). Thats in your example if you create two objects with same i1,i2 values then the hash code returned should be same. But if i1,i2 values are different the object cannot be considered equal(but doesnt mean the hashcode has to be different...).

In short, Every time with same inputs the output hashcode on an object should be same.

You have given the choices, but whats the question?
 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See in effective java programming Language Guide, item 8, to see a good way to make a hashCode().


'A good hash function tends to produce unequal hash codes for unequal objects. Ideally, a hash function should distribute any reasonable collection of unequal instances uniformly across all possible hash values.'



A rule is given.
In short, in your case, it will be :

public int hashCode()
{
result = 17;
result = result * 37 + getI1();
result = result * 37 + getI2();
return result;
}


So the answer E will best distribute unequals Test objects.
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First glance to me suggests you have violated the fundametal rule, "never calculate the hashCode from non-final fields".
 
author
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This would be easier if we knew what the sample test quesion was asking for. If it's asking which statements produce legal hashcodes, all of them do. If it's asking which produces the best hashcode, then I agree with (E), though I could also talk myself into (D).

My rule of thumb is that a hashcode should do a pretty good job of reflecting the uniqueness of an instance, by being a function of the instance's important state variables. What's that mean? It's open to debate, but the contract (see API page for Object.hashCode()) is that if a.equals(b) then a.hashCode() == b.hashCode().

The reason for all this is so that collections will work properly. Many collections (especially map implementations) use hashcodes to figure out how to store their contents. If a hashcode algorithm doesn't do a good job of distinguishing unequal objects (remember, unequal obs may have the same hashcode: it's just the reverse case that's forbidden) then collections perform inefficiently. On the other hand, if a hashCode() method always returns unequal hashcodes for unequal objects, that' not always ideal either. If the algorithm performs a ton of computation on the instance's state variables, then any collection that calls hashCode() will still run inefficiently.

So the point is to have a hashCode() method that strikes a good balance between distinction and performance.

What about the rule that only final variables should be part of the calculation? Well, if you stick to that you'll never get into a certain kind of trouble that's really hard to debug. If an object is stored in a collection, and that object's state changes in a way that affects hashCode() and/or equals(), really weird things can happen. So if the state is final, you can never experience those really weird things. However, I don't always make my state final, because sometimes I just can't. But when I have non-final state, I'm extra careful.

Hope this helps.
 
Shweta R Dhaneshwar
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot for explaining in detail.
Regards,
Shweta
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic