Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Strings behaving in abnormal manner

 
Shrinivas Mujumdar
Ranch Hand
Posts: 328
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Friends,
see the following code & output:
class Abcd
{
public static void main(String[] args)
{
String s1="seed";
String s2="seed";
System.out.println(s1.hashCode()+" "+s2.hashCode());
System.out.println(s1==s2);
String s3=new String("SEED");
String s4=new String("SEED");
System.out.println(s3.hashCode()+" "+s4.hashCode());
System.out.println(s3==s4);
System.out.println("Hello World!");
}
}


output:
3526257 3526257
true
2541169 2541169
false
Hello World!

Press any key to continue...


Don't you think that line
System.out.println(s3==s4);
should print "true" but it is producing "false" even if the hashCode is same.

Any logic behind this?

Regards,
Shrinivas
 
Ulf Dittmer
Rancher
Pie
Posts: 42967
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should compare Strings (and Objects in general) using 'equals', not using '=='. equals tests equality of the object values, while == tests equality of object references. Even for non-mutable, seemingly identical, objects like the ones in your example, the references may or may not be the same.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in other words, the behaviour is quite normal
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two distinct objects that are unequal (according to the Object.equals(Object) method) may produce the same hash codes (according to the Object.hashCode() method). In fact, unless construction is controlled (which best practices mandates anyway, but common practice ensure that it is prolific), it's impossible to enforce - all you need to do is construct 2^32 + 1 unequal instances and a hash code collision is guaranteed.

This may be all beside the point, since your question is unclear, in which case, ignore it.
 
Shrinivas Mujumdar
Ranch Hand
Posts: 328
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanx Everybody,

One more fact is in String hashCode() is overridden & it do not represent memory address but hashCode depends on String Contents.string (2 different objects ) can have same hashcode provided that their contents are same.


Shrinivas
 
Steve Morrow
Ranch Hand
Posts: 657
Clojure Spring VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One more fact is in String hashCode() is overridden & it do not represent memory address but hashCode depends on String Contents.string (2 different objects ) can have same hashcode provided that their contents are same.

Indeed. Objects that are equal *should* generate the same hash code.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Shrinivas Mujumdar:
string (2 different objects ) can have same hashcode provided that their contents are same.


They *must* have the same hashcode if they are equals, and they *may* have the same if they are not equal.
 
Steve Morrow
Ranch Hand
Posts: 657
Clojure Spring VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They *must* have the same hashcode if they are equals
Per the contract, absolutely. There was no reason for me to shy away from the stronger term.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic