File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes  Doubt  About  Hash Code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark " Doubt  About  Hash Code" Watch " Doubt  About  Hash Code" New topic
Author

Doubt About Hash Code

Thennam Pandian
Ranch Hand

Joined: Oct 11, 2005
Posts: 163
Dear Friends,

i want to know how they are generating hash code?

what is use of hash code?
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

Is that 'they' as in "You know what they say about Michael"?

There is a good introduction on the why and how at the Java glossary.

The short answer is that it is handy having a fast way to 'guess' whether two objects are the same, then compare them only when you have to. Hashcodes should be implemented to give a good 'spread' of values, so that there is a reduced chance of two objects having the same code. This won't break things, even having several is fine, but if you have a lot then you will start to lose the advantage of hashcodes.

A good implementation is in the link provided, and also in Joshua Bloch's "Effective Java".

Dave
u johansson
Ranch Hand

Joined: Dec 27, 2005
Posts: 47

what is use of hash code?


Do you mean the hashCode method?

The main use is to allow classes to be used with hash table based collections such as HashTree and HashMap. For that to work properly hashCode (defined in Object) must be overridden in conjunction with equals (also defined in Object).

Both equals and hashCode deal with the content of objects. Equals should return true when two objects are considered equal based on their contents. The rule for hashCode is that if two objects are equal (in the sense that equals return true) the hashCode method of both objects MUST return the same int. BUT they MAY also do that if they're not equal. The latter is called a collision and it's allowed but it should be avoided because it degrades the access performance when such objects are stored in collections.
u johansson
Ranch Hand

Joined: Dec 27, 2005
Posts: 47

The short answer is that it is handy having a fast way to 'guess' whether two objects are the same, then compare them only when you have to.


There's no reason to assume that hashCode should be a faster way to test for object equality. In fact the opposite is true. Equals is likely to be faster. It's because a good hashCode has to consider the entire content (in order to guarantee an even distribution of hash codes), whereas equals only has to compare content up to the point where it can be established that two objects are not equal. And in addition, hashCode requires you to make two hashCode calls and then an additional call to equals in the case the hashCode ints turn out to be equal. Using equals is always just one call.

So, it's much better to use equals to compare objects for content equality. It's both handier and likely to be faster than (mis)using hashCode for that purpose.
[ December 30, 2005: Message edited by: u johansson ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
UJ, again could you please check you private messages? Thank you.

If the objects in question are immutable, you can evaluate the hash code once and cache it. After which it's extremely quick. The string class does this, for example. Although it seems they fail to take full advantage of this (looking at the source in the latest JDK). I would want the equals() method to include something like this immediately after checking that the two strings lengths are equal:

This would result in a slightly longer execution when the two strings are equal, but considerably faster execution when they're not - if hashCode() has ever been called previously. Maybe they figured this situation doesn't come up often enough to optimize for, since the most common case is that two unequal strings will have different lengths anyway, and that already gets rejected pretty quickly. Oh well. Still, I recommend using lazy evaluation for the hash code of any immutable type. Unless the hash is already trivial to calculate - e.g. in the Integer class.

As for David's answer, he did say it was "the short answer". I took it to be a bit of a simplification - if you're really just interested in comparing only two values, once, then equals() is usually the way to go. But if you're comparing a lot of different values, and want some way to organize them efficiently to minimize the computations overall, that's where hash code comes in. Anyway, the references cited by David give more than enough info for the original poster to learn what they need, I think.


"I'm not back." - Bill Harding, Twister
Adam Richards
Ranch Hand

Joined: Nov 03, 2005
Posts: 133
What do you "doubt"?
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
You can usually assume "doubt" in this context means "question". I see this alot from our Indian friends and it's understandable being a second language, but I'm not sure why that particular culture confuses doubt and question so often where other's don't.
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by u johansson:


Do you mean the hashCode method?

The main use is to allow classes to be used with hash table based collections such as HashTree and HashMap. For that to work properly hashCode (defined in Object) must be overridden in conjunction with equals (also defined in Object).

Both equals and hashCode deal with the content of objects. Equals should return true when two objects are considered equal based on their contents. The rule for hashCode is that if two objects are equal (in the sense that equals return true) the hashCode method of both objects MUST return the same int. BUT they MAY also do that if they're not equal. The latter is called a collision and it's allowed but it should be avoided because it degrades the access performance when such objects are stored in collections.


I kind of always thought equals() should return true when two Objects should be considered the same. Whether or not that has anything to do with it's contents is a matter of class design and implementation isn't it? If I can guarantee that no more than one equivalent instance of an Object will ever exist, then == will be sufficient will it not?

I believe the implementations provided by Object are adequate for HashMap/Tree to work so I'm not sure why you say they must be overridden.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Ken Blair:

I believe the implementations provided by Object are adequate for HashMap/Tree to work so I'm not sure why you say they must be overridden.


Ulrike probably meant to say that if you override equals, you also have to override hashcode accordingly.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by Ilja Preuss:


Ulrike probably meant to say that if you override equals, you also have to override hashcode accordingly.


Okay I see what they meant now.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I always throw this in: If your objects might ever go into an ordered collection, like TreeSet, override compareTo as well. Nobody else ever brings that up so I wonder if I'm off base. Doesn't that make sense?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
uj johansson
Greenhorn

Joined: Dec 31, 2005
Posts: 23
Originally posted by Stan James:
I always throw this in: If your objects might ever go into an ordered collection, like TreeSet, override compareTo as well. Nobody else ever brings that up so I wonder if I'm off base. Doesn't that make sense?

That makes perfect sense. To enable your own class to work with any collection, override equals and hashCode of Object and implement the Comparable interface.
uj johansson
Greenhorn

Joined: Dec 31, 2005
Posts: 23
Originally posted by Ken Blair:

I believe the implementations provided by Object are adequate for HashMap/Tree to work so I'm not sure why you say they must be overridden.


The situation you describe happens only in exceptional cases. Basically it requires an implementing technique called "pooling" to be used. This guarantees that each possible object content is represented by exactly one object reference, (that is you have a one-to-one relation between reference and content.) This is the case for String literals for example and that's why these can be compared using == (although it's recommended to use equals).

So generally it's required that you override equals and hashCode to make a class work with hash table based collections.
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by uj johansson:
The situation you describe happens only in exceptional cases. Basically it requires an implementing technique called "pooling" to be used. This guarantees that each possible object content is represented by exactly one object reference, (that is you have a one-to-one relation between reference and content.) This is the case for String literals for example and that's why these can be compared using == (although it's recommended to use equals).

So generally it's required that you override equals and hashCode to make a class work with hash table based collections.


Let's clarify the meaning. Is it: 1) you must override equals() and hashCode() for a hash table based collection to work, or 2) overridding neither may not be necessary in many situations including but not limited to pooling, but if you override one you must override the other.

I was under the impression it was #1. Ija was under the impression you meant #2, which I agreed with. Your further response has confused me as to which you mean. If it's #2 then, once again, I agree. If it's #1, I'm not so sure...
[ January 03, 2006: Message edited by: Ken Blair ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Doubt About Hash Code
 
Similar Threads
doubt regarding hashcode
hashcode
Mock exam by sreenivasa kumar majji - Q6
Hash code
equal() method of class Object