jQuery in Action, 3rd edition
The moose likes Java in General and the fly likes string == and hashcode Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "string == and hashcode" Watch "string == and hashcode" New topic

string == and hashcode

John Summers
Ranch Hand

Joined: Oct 06, 2003
Posts: 125
hi all,
The code below prints "not == -891985903 -891985903".
Can anyone explain why:
a) a and b are not the same object. is it perhaps because the trim occurs at run time?
b) howcome a does not == b? I thought == worked by comparing hashCodes, and the hashcodes are the same.

public static void main(String[] args)
String a = " string ".trim();
String b = "string";

if (a == b)
System.out.println ("==");
System.out.println ("not == " +
a.hashCode() + " " + b.hashCode());
Ernest Friedman-Hill
author and iconoclast

Joined: Jul 08, 2003
Posts: 24199

is it perhaps because the trim occurs at run time?

Yes, a and b are not the same object. The result of calling " string".trim() is computed at runtime and a new, distinct String "string" is created, unrelated to the pre-existing String literal with the same value.

I thought == worked by comparing hashCodes,

Nope, not at all. "==" works by comparing physical chunks of memory, always. You can have an arbitrarily large number of Strings, all of which contain the same characters in the same order, but which are physically distinct objects. They'll all have the same hashCode(), and they'll all be not equal according to "==".
The equals() method, on the other hand, is supposed to return true for equivalent objects; so given two distinct String objects s1 and s2 both containing the characters "string", s1.equals(s2) would be true, while s1 == s2 would be false.
It very rarely makes any sense to use == to compare strings. Use equals() instead.

[Jess in Action][AskingGoodQuestions]
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
You should note that objects with the same hashcode are not guaranteed to be equal. A hashcode method that returns a constant 0 for all objects is a correct (although inefficient) implementation according to the specs.
Why is hashcode not the same as equals? hashCode() always returns an int. For any int I can create an equaivalent string. For example:
int a = 1;
String as = "1";
int b = 132;
String bs = "132";
So clearly I can create a different String for every possible int. But I can also create Strings that don't have an int equaivalent:
String as1 = "1 + some other stuff";
This means that ints can not represent all the possible Strings. So there must be some cases where two Strings will have equal hash codes even when the Strings themselves are not equal.

Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
I agree. Here's the link: http://aspose.com/file-tools
subject: string == and hashcode
It's not a secret anymore!