what is hashCode()?

[touchstone]

Code Select Expand


String strobj = new String ("abc");
System.out.println(strobj.hashCode() );


i am getting a number 96354. what does it mean?
java API says" public int hashCode()      Returns a hash code value for the object "

what does it mean? is it address??

[iago]

It's a code that uniquely identifies the item.  It's defined in Object, I believe, as the address in memory where the object resides, but other objects may override it and specify their own hashcodes.  Strings may or may not, I'm not sure.

[iago]

Another point - the hashCode of an object is only guarenteed to be consistant for a single object for the duration of a program.  It may be different next time you run the program.

[touchstone]

ok, you mean its address, fine...but  look, my output is 96354 ...its a whole number....generally addresses are represented in hexadecimal . in C also, if you print addresses by %u it will show output in hex.

anyway,

second point, i run the code several times, but its value(96354) is not changing.

third point, you are talking about  overriding, is this like below?

Code Select Expand


public class MyClass
{
public static void main (String args[])
{
 String strlit = "SCJP";

 String strobj = new String ("SCJP");

 System.out.println(strlit.hashCode() == strobj.hashCode());
}
}



if i print individually .....


System.out.println(strobj.hashCode() );

and

System.out.println(strlit.hashCode());

both of them are printing  96354 .....so, both the objects have taken the same memory place without conflict!!

thanks

[iago]

String actually implements a polynomial hashcode, so it won't change for strings.  Although I wouldn't guarentee that, because the definition of hashCode doesn't.

What that means is the String class has something like this:

Code Select Expand

class String
{
.......
int hashCode()
{
 int code = 0;
 for(int i = 0; i < this.length; i++)
   code += this.charAt(i);
 return code;
}
.....


Clearly, it's more complicated than that, but it's a similar idea.  

[Banana fanna fo fanna]

Actually, it is documented behavior for String:

public int hashCode()
Returns a hash code for this string. The hash code for a String object is computed as

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

using int arithmetic, where s is the ith character of the string, n is the length of the string, and ^ indicates exponentiation. (The hash value of the empty string is zero.)

Overrides:
hashCode in class Object

Now, the default hashCode() implementation does the memory address, BUT DO NOT DEPEND ON IT. The only thing hashCode() is meant for is this: if two objects are the same class and have equal hash codes, then they are the same object. In fact, thats how equals() is implemented.

[Adron]

Now, the default hashCode() implementation does the memory address, BUT DO NOT DEPEND ON IT. The only thing hashCode() is meant for is this: if two objects are the same class and have equal hash codes, then they are the same object. In fact, thats how equals() is implemented.

That doesn't sound right. If two objects are the same class and have equal hash codes, they *may* be the same object?

[iago]

No, then it IS the same object.  By default, it uses memory address

[Adron]

No, then it IS the same object.  By default, it uses memory address

The string algorithm seems like it might return the same hashcode for different strings.

[iago]

No, then it IS the same object.  By default, it uses memory address

The string algorithm seems like it might return the same hashcode for different strings.

The String class overrides it, so that doesn't count

[Adron]

It counts to show that you shouldn't trust two objects with the same hashCode to be the same.

[iago]

It counts to show that you shouldn't trust two objects with the same hashCode to be the same.

hmm, I guess it can be argued that it doesn't matter if two strings are the same object.  Since strings can never be changed, if you have:
a = "abc" and
b = "abc", for all intents and purposes, they are the same object.

[Banana fanna fo fanna]

It counts to show that you shouldn't trust two objects with the same hashCode to be the same.

Yes you should.

[Kp]

It counts to show that you shouldn't trust two objects with the same hashCode to be the same.

Yes you should.

By your own quote of the algorithm, was it not established that two String objects with differing content can theoretically produce the same hashcode?  There's only 32 bits of hashcode, and since String can contain things much longer than 32 bits, there's not a 1-1 mapping between a String and a hashcode.  Thus, it is not safe to trust that matching hashcodes mean the objects are identical.

[Banana fanna fo fanna]

It counts to show that you shouldn't trust two objects with the same hashCode to be the same.

Yes you should.

By your own quote of the algorithm, was it not established that two String objects with differing content can theoretically produce the same hashcode?  There's only 32 bits of hashcode, and since String can contain things much longer than 32 bits, there's not a 1-1 mapping between a String and a hashcode.  Thus, it is not safe to trust that matching hashcodes mean the objects are identical.

That's correct, however, in Java, the equals() method by default just makes sure hashCode()'s are equal. Thus, in Java you should be able to trust that if the two hashCodes() are the same and the classes are the same, the two objects are the same.