S2.equals(7) is false, but (S2 == 7) is true. Short S2 = new Short((short)7); Why?

[Harry Henriques]

Hi

I've been looking at some conditionals in preparation for the SCJP exam. Can you explain the following result that I observed in an actual program.

Short S2 = new Short((short) 7 );

if ( S2.equals(7) )
    System.out.println("true");
else
    System.out.println("false");

if ( S2 == 7 )
    System.out.println("true");
else
    System.out.println("false");

RESULT:

false
true

I understand why the first conditional is false, but why is the second conditional true. S2 is a Short wrapper, and 7 is an integer primitive.

[armando fonseca]

Numbers between -128 and 127 will give true when using wrappers and the equality ==.
Now, if you want to know why is the implementation that way , i will recomend you to look the jls. You don't need to know the why of the implemenation for the scjp but basically it has something to do with memory optimization.

[Ankit Garg]

When you compare a wrapper and primitive value using any comparison operator like == or != or > ..... then the wrapper is first unboxed for the comparison. So S2 == 7 becomes S2.shortValue() == 7 and that's why its true...

[Christophe Verré]

[rant]I hate auto-boxing/unboxing and all the confusion which comes with it[/rant]

[Jesper de Jong]

armando fonseca wrote:Numbers between -128 and 127 will give true when using wrappers and the equality ==.

But that is in this case not why the second answer is 'true'!

The fact that == returns true in some cases is because classes like Integer have a cache of Integer objects for all the values between -128 and 127, and if you call Integer.valueOf(int) with a value in that range, the method will return an Integer object from the cache. Note that autoboxing calls Integer.valueOf(int) to automatically box an integer.

In the case above, S2 is created with the new operator. It is not an object from the cache - even though the value is 7. When you compare it to an object from the cache, the result will be false.

[armando fonseca]

Jesper Young wrote:

armando fonseca wrote:Numbers between -128 and 127 will give true when using wrappers and the equality ==.

But that is in this case not why the second answer is 'true'!

The fact that == returns true in some cases is because classes like Integer have a cache of Integer objects for all the values between -128 and 127, and if you call Integer.valueOf(int) with a value in that range, the method will return an Integer object from the cache. Note that autoboxing calls Integer.valueOf(int) to automatically box an integer.

In the case above, S2 is created with the new operator. It is not an object from the cache - even though the value is 7. When you compare it to an object from the cache, the result will be false.

You are right... I'm a shame.... just keep it between us.
regards,
Armando.

[Jesper de Jong]

No problem, it isn't a shame that you have to learn all those tricky details!

[vallinayagam subramanian]

I guess this s2 == 7 is evaluating to true because of Unboxing and not because of the caching of -128 to 127.
The reason being, s2 == 200 also evaluates to true.

[Nitish Bangera]

Yeah true and has been already clearly explained by Ankit above. I think caching comes into play when we compare 2 objects with the values and well i don't like the sound of the caching that much....i like referring it as pool like the Strings do. Well wrappers and Strings have this special thing called pool well i don't think not all wrappers do... which ones hmm readers guess

[Christophe Verré]

Closing this thread. Continue the discussion there.