• 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() on diferent applications

 
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
According to Dan's exam, this sentence is true.
"Within any one execution of the Java application, the hash code contract requires that each invocation of the hashCode method on the same instance of class C must consistently return the same result as long as the fields used for the equals comparison remain unchanged."

But the java api says that the hash code does not need to remain consistent from one execution of an application to another.
Having this in mind, wouldn't Dan's afirmative be wrong?
 
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't see that these are in conflict.

"Within any one execution of the Java application, the hash code" must be consistent ... ; but "the hash code does not need to remain consistent from one execution of an application to another."
[ March 01, 2005: Message edited by: marc weber ]
 
Leandro Melo
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, I misunderstood.
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Within any one execution of the Java application, the hash code contract requires that each invocation of the hashCode method on the same instance of class C must consistently return the same result as long as the fields used for the equals comparison remain unchanged



Yes it is wrong, but not in the way that you think.
The contract does not demand what has been stated, but something else, specifically, that "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." This is different to what has been stated.

The challenge now is to "change the fields" used for the equals comparison, while still meeting the real contract. i.e. to contradict the misinterpretation and the reality. It can be done

<spam>
JTiger unit test framework will allow you to assert that your objects meet all aspects of the equals/hashCode method contracts among many other useful assertion features. http://www.jtiger.org/ I plan to release it within the next two weeks - political issues pending.
</spam>
[ March 01, 2005: Message edited by: Tony Morris ]
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Tony]: The contract does not demand what has been stated, but something else...

Ummm... you sure about that? Looking at the API for hashCode() in Object, I see three bullet points. This question was about a close paraphrase of the first bullet point, and you seem to be quoting the second bullet point.
[ March 01, 2005: Message edited by: Jim Yingst ]
reply
    Bookmark Topic Watch Topic
  • New Topic