what is hashCode()?

[Kp]

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.

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!)

[iago]

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.

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!)

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.

[Adron]

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

[dxoigmn]

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

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 Select Expand


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


[Adron]

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".

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

[dxoigmn]

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

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 Select Expand


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


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

[Banana fanna fo fanna]

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)

[Adron]

Ah, back to the old statement:

If two objects are the same class and have equal hash codes, they *may* be the same object

[iago]

Wow, you can has an integer:

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