about how == works

[priyavardheesh]

hi,
i have doubt about how this operator == works.
Boolean b = new Boolean("false");
String s = "false";

s == b.toString() returns true
but, the same thing tried with other wrapper classes fails
Integer i = new Integer("99");
String s = "99";
s == i.toString() returns false

[Anonymous]

That's a tough one! My guess is that "false" and "true" being literal Strings are created in the String pool at class loading time, and since you did not create your first String s with the new operator, that it also points at the "false" String literal in the String pool. Notice that if you create the s with the new operator, that the == comparison doesn't work.
The wrapper classes don't work (as you say), because the toString() method creates a new String, thus they are different objects and == fails.

[Ajith Kallambella]

Even I thought so, but I was wrong.
Instead of Boolean("true"),
try either
Boolean b = new Boolean(new String("false"));
OR
Boolean b = new Boolean(null); // same as "false"
The comparison with 's' would still return true.
My guess is the toString() method is referring to the
same anonymous string created in the string pool pointed
to by 's'.
Java Nut, when you say wrapper classes dont' work, are
you saying Boolean is not a wrapper class?
Ajith

[Anonymous]

Scratch that last comment! Integer converts "99" to an int and then wraps that int in the Integer. It does not maintain a pointer to the "99" string that was passed in, where the Boolean object does to the "false" literal string. The Integer must create a new String when toString() is called, whereas Boolean returns a pointer to the string that was passed to it.

[Ajith Kallambella]

But it still doesn't explain why
Boolean b = new Boolean(null); // same as "false"
works the same way. Here there is no literal string
involved. Perhaps the .toString searches the string pool
to see if the same value exists.
The following code substantiates my argument.
s2 = b.toString();
System.out.println(s==s2);
Ajith

[Anonymous]

Boolean can have only 2 possible values, "true" and "false". Obviously, whatever kind of string you pass in the constructor doesn't matter, because all will be resolved to the "true" or "false" literal. My guess is the programmers of the JDK knew that and therefore just had these two literals in the string pool to point to. No use having other "true" and "false" strings laying around, is there? Just a simple, smart optimization.

[Ajith Kallambella]

Smart reasoning too!

[Anonymous]

At least it is consistent with what we've learned studying for the SCJP2 exam:
Boolean b = new Boolean("true");
String st = new String("true");
System.out.println(st == b.toString());
Returns false as they are pointing to different String objects.
Boolean b = new Boolean("true");
String st = "true";
System.out.println(st == b.toString());
Returns true as they are pointing to the same String object (in the pool).