[code]
String strobj = new String ("abc");
System.out.println(strobj.hashCode() );
[/code]

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??

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.

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.

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]
public class MyClass
{
public static void main (String args[])
{
String strlit = "SCJP";

String strobj = new String ("SCJP");

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

[/code]

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

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]class String
{
.......
int hashCode()
{
int code = 0;
for(int i = 0; i < this.length; i++)
code += this.charAt(i);
return code;
}
.....
[/code]

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

Actually, it is documented behavior for String:

[quote]
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[i] 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
[/quote]

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.

[quote author=St0rm.iD link=board=34;threadid=5479;start=0#msg46377 date=1077912151]
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.
[/quote]

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

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

[quote author=iago link=board=34;threadid=5479;start=0#msg46391 date=1077915530]
No, then it IS the same object. By default, it uses memory address :)
[/quote]

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

[quote author=Adron link=board=34;threadid=5479;start=0#msg46395 date=1077917523]
[quote author=iago link=board=34;threadid=5479;start=0#msg46391 date=1077915530]
No, then it IS the same object. By default, it uses memory address :)
[/quote]

The string algorithm seems like it might return the same hashcode for different strings.
[/quote]

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

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

[quote author=Adron link=board=34;threadid=5479;start=0#msg46434 date=1077930727]
It counts to show that you shouldn't trust two objects with the same hashCode to be the same.
[/quote]

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.

[quote author=Adron link=board=34;threadid=5479;start=0#msg46434 date=1077930727]
It counts to show that you shouldn't trust two objects with the same hashCode to be the same.
[/quote]

Yes you should.

[quote author=St0rm.iD link=board=34;threadid=5479;start=0#msg46526 date=1077986550]
[quote author=Adron link=board=34;threadid=5479;start=0#msg46434 date=1077930727]
It counts to show that you shouldn't trust two objects with the same hashCode to be the same.
[/quote]Yes you should.[/quote]

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.

[quote author=Kp link=board=34;threadid=5479;start=0#msg46530 date=1077990732]
[quote author=St0rm.iD link=board=34;threadid=5479;start=0#msg46526 date=1077986550]
[quote author=Adron link=board=34;threadid=5479;start=0#msg46434 date=1077930727]
It counts to show that you shouldn't trust two objects with the same hashCode to be the same.
[/quote]Yes you should.[/quote]

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.
[/quote]

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.

[quote author=St0rm.iD link=board=34;threadid=5479;start=0#msg46584 date=1078010077][quote author=Kp link=board=34;threadid=5479;start=0#msg46530 date=1077990732]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.[/quote]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.[/quote]

Assuming you are correct about Object::equals(), that would indicate that Java natively supports giving incorrect answers about equality. As I stated in my previous post, hashCode will produce a many-to-1 mapping by its very nature. Therefore, it is unsafe to rely upon matching hashCodes as proof that the underlying objects are identical. It may be highly probable, but is by no means certain, that such is the case if the underlying objects have overridden hashCode (as Java::lang::String does!)

[quote author=Kp link=board=34;threadid=5479;start=15#msg46597 date=1078015445]
[quote author=St0rm.iD link=board=34;threadid=5479;start=0#msg46584 date=1078010077][quote author=Kp link=board=34;threadid=5479;start=0#msg46530 date=1077990732]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.[/quote]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.[/quote]

Assuming you are correct about Object::equals(), that would indicate that Java natively supports giving incorrect answers about equality. As I stated in my previous post, hashCode will produce a many-to-1 mapping by its very nature. Therefore, it is unsafe to rely upon matching hashCodes as proof that the underlying objects are identical. It may be highly probable, but is by no means certain, that such is the case if the underlying objects have overridden hashCode (as Java::lang::String does!)
[/quote]

Generally, hashCode returns the address in memory of the object, which can only have a single object. For strings, equality is different, but for objects hashCode seems to make them unique.

I don't get the hashcode that was brought up earlier in this thread. What's wrong with this:

Posted hashcode: 96354 = 0x17862

String: SCJP 0x53 0x43 0x4a 0x50

0x53 * 31^3 + 0x43 * 31^2 + 0x4a * 31 + 0x50 = 2539414

[quote author=Adron link=board=34;threadid=5479;start=15#msg46693 date=1078059278]
I don't get the hashcode that was brought up earlier in this thread. What's wrong with this:

Posted hashcode: 96354 = 0x17862

String: SCJP 0x53 0x43 0x4a 0x50

0x53 * 31^3 + 0x43 * 31^2 + 0x4a * 31 + 0x50 = 2539414
[/quote]

That is correct, however in his first post he mentions the test string is "abc" which is the correct string for hashCode() == 96354. However, later down he metions "SCJP" but incorrectly gives the hashCode() for the string "abc".

[code]
public class MyTest {
public static void main (String args[])
{
String scjp = "SCJP";
String abc = "abc";

System.out.println(scjp.hashCode()); // Should output: 2539414
System.out.println(abc.hashCode()); // Should output: 96354
}
}

Outputs:
2539414
96354
[/code]

[quote author=dxoigmn link=board=34;threadid=5479;start=15#msg46716 date=1078077553]

That is correct, however in his first post he mentions the test string is "abc" which is the correct string for hashCode() == 96354. However, later down he metions "SCJP" but incorrectly gives the hashCode() for the string "abc".
[/quote]

Ah, ok. And then in Java, "Raho" is a string that is the same string as "SCJP"?

[quote author=Adron link=board=34;threadid=5479;start=15#msg46724 date=1078079406]
Ah, ok. And then in Java, "Raho" is a string that is the same string as "SCJP"?
[/quote]

No, unless you do a raho.hashCode() == scjp.hashCode(). However, you don't do this. You'd normally use equals or compareTo and their case-insensitive equivalents.

Example:
[code]
public class MyTest {
public static void main (String args[])
{
String scjp = "SCJP";
String raho = "Raho";

System.out.println(scjp.hashCode());
System.out.println(raho.hashCode());
System.out.println(scjp == raho);
System.out.println(scjp.equalsIgnoreCase(raho));
System.out.println(scjp.compareToIgnoreCase(raho)); // compareTo returns 0 if they strings are the same
System.out.println(scjp.hashCode() == raho.hashCode());
}
}

Outputs:
2539414
2539414
false
false
1
true
[/code]

Edit: note that changing the above code to use the case-sensitive equals and compareTo renders the same results.

Make sure .equals() returns false.

If so, I guess String overrides the equals() method then.

EDIT: looks like I got it backwards:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object)

Ah, back to the old statement:

[quote author=Adron link=board=34;threadid=5479;start=0#msg46380 date=1077913684]
If two objects are the same class and have equal hash codes, they *may* be the same object
[/quote]

Wow, you can has an integer:

[quote]hashCode
public int hashCode()Returns a hash code for this Integer.

Overrides:
hashCode in class Object
Returns:
a hash code value for this object, equal to the primitive int value represented by this Integer object.
See Also:
Object.equals(java.lang.Object), Hashtable[/quote]