String literal and String object comparison

[vittal rao]

Hi,

Can i know the reason for the String literal assignment .

String str1 = new String("abc");
String str="abc";

System.out.println(str==str1);
System.out.println("Str memory-->"+str.hashCode());
System.out.println("Str1 memeory-->"+str1.hashCode());

output:
false
Str memory-->96354
Str1 memeory-->96354

Even though a new String object is created both of them have same address still str1=str gives false.
This is confusing .

[Kee Kee moon]

If we use the keyword "new" to create a string "abc" ,(String str1 = new String("abc)), it creates a new String object, whereas String str="abc" has no object.
If we want to compare these two strings, we use System.out.println(str1.equals(str)); ==> the out put will be "true"

Please read http://leepoint.net/notes-java/data/expressions/22compareobjects.html.

(ps. I am learning, any correction and tips are welcome)

vittal rao wrote:Hi,

Can i know the reason for the String literal assignment .

String str1 = new String("abc");
String str="abc";

System.out.println(str==str1);
System.out.println("Str memory-->"+str.hashCode());
System.out.println("Str1 memeory-->"+str1.hashCode());

output:
false
Str memory-->96354
Str1 memeory-->96354

Even though a new String object is created both of them have same address still str1=str gives false.
This is confusing .

[Rob Spoor]

The hash code does not return the memory address. The hash code as returned by Object.hashCode() and System.identityHashCode() returns something that is possibly but not necessarily related to the memory address. However, classes can override the hashCode() method to return something completely different. In fact, the following class is perfectly fine:

class Test
{
    public int hashCode() { return 42; }
}

String also overrides hashCode() but a [s]bit[/s] lot more sophisticated - it uses the actual characters for the hashCode() return value, and that is why both your strings have the same hashCode() return value even though they are not the same using ==.

[Campbell Ritchie]

Rob Prime wrote: . . . In fact, the following class is perfectly fine . . .

Careful, Rob, they will believe you

[Rob Spoor]

I said fine, not good. It will behave badly in HashMaps and HashSets. Perhaps the correct word is "legal".

[Patricia Samuel]

It means , since they both have same value, hence returning the same hashcode. Please confirm.

[Campbell Ritchie]

I presume you are familiar with the Object#hashCode() specification? Returning the same value from all instance via the hashCode method will satisfy the requirement that values returning true from equals() have the same hash code.

But it doesn't satisfy the recommendation that objects returning false from equals() return different hash codes if possible. So all objects of that class would go into the same bucket in a hash-based map or set.