Question about Strings and Hash Code

[Shivaji Marathe]

I encountered the following code and explanation in Core Java2 ( page 97 )

  
String s ="Ok";
StringBuffer sb= new stringBuffr(s);
System.out.println(s.hashCode() + " " + sb.hashCode() );
String t="Ok";
StringBuffer t= new stringBuffr(t);
System.out.println(t.hashCode() + " " + tb.hashCode() );

The hashcode for both strings is same and the hashcode for both the string buffers will be different from each other. The explanation is that the hashcode of the String object is based on the contents of the String . And the hashcode of the StringBuffer is basically calculated by the hashCode() function of the Object class, which uses the memory address to calculate the hash code.
I thought that the compiler will encounter two identical String literals and therefore, both Strings s and t refer to the same memory location and so their hash codes are identical.
Can someone shed more light on this ?
TIA

[Jessica Sant]

I think you're both right:
Notice that java.lang.StringBuffer doesn't override the .hashCode() method -- so it will be determining the hashCode() as if it were an Object.
Whereas the java.lang.String class DOES override the .hashCode() method, so it returns the .hashCode() for the String literal.
[ June 03, 2002: Message edited by: Jessica Sant ]

[Ilja Preuss]

Originally posted by Shivaji Marathe:
I thought that the compiler will encounter two identical String literals and therefore, both Strings s and t refer to the same memory location and so their hash codes are identical.

s and t would even have identical hashcodes if refering to different memory locations. Try it with t = new String(s);
sb and tb don't (necessarily) have identical hashcodes, even with identical string content.
Notice that the implementation of Object.hashCode() doesn't need to use the memory location - it's just an implementation detail of the current JVM.