How == returns false even though two Strings s1 and s3 having same hashcode? [duplicate]

Answer 1

When you do:

String a = "xyz"

while creating the string, the JVM searches in the pool of strings if there already exists a string value xyz, if so 'a' will simply be a reference of that string and no new String object is created.

But if you say:

String a = new String("xyz")

you force JVM to create a new String reference, even if "xyz" is in its pool. and == compares the references. That's why you are getting the false result.

Answer 2

For two Objects the == operator compares their pointer reference. So unless they are actually the exact same object it's never true.

Answer 3

In a correct implementation of equals and hashCode you have the following implications for two objects a and b (that are not null):

if a == b then also a.equals(b)

if a.equals(b) then also a.hashCode() == b.hashCode()

Both implications cannot be reversed in general.

Answer 4

Despite the comments above, I suspect that you already understand that == determines if two references point to the same object (or are both null), and that you should use equals() if you want to compare two strings for data-equality.

Rather, I think what you're missing is that the hashCode() method corresponds to the equals() method in this respect; it's based on the data in an object, and in fact, it's specified that classes should always implement hashCode() in such a way that if a.equals(b), then a.hashCode() == b.hashCode(). (Of course, there's nothing in the language that enforces this.) The analogue of == that you're looking for is the System.identityHashCode() method.

However, even there it should be noted that System.identityHashCode() does not guarantee that distinct instances will have distinct identity hash codes. (It can't, because it's possible to have more than 2³² objects in a JVM at the same time . . . granted, not all JVMs support that; but nothing in the Java language specification forbids it.)