Query: In boxing why == & != both works

[raul saini]

For e.g.:

  

Integer i1=42;
Integer i2=42;

if(i1==i2)
System.out.println("Equal");

if(i1 != i2)
System.out.println("Different");

  

In this both == & != works.

How?

[Pramod P Deore]

In this here is only first condition is true, not second one

[Joanne Neal]

Raul - what do you mean by both == and != works ?
Are you saying that code prints
Equal
Different

[raul saini]

Actually it was given in Kathy sierra SCJP book page no. 254-256, that:

Integer i1 = 1000;
Integer i2 = 1000;
if(i1 != i2) System.out.println("different objects");
if(i1.equals(i2)) System.out.println("meaningfully equal");

Produces the output:
different objects
meaningfully equal

And,

Integer i3 = 10;
Integer i4 = 10;
if(i3 == i4) System.out.println("same object");
if(i3.equals(i4)) System.out.println("meaningfully equal");

This example produces the output:
same object
meaningfully equal

But when I executed != failed, But I'm still not able to get what the book meant.

[Joanne Neal]

Note the difference in the values of the Integers.
What the example is trying to show is how Integer values between -127 and 128 are cached, but values outside that range are not*.

Search the forums. This question crops up a lot.







*Actually they can be but it is not mandatory.

[Jesper de Jong]

This is because of how autoboxing and the Integer class work.

Autoboxing means that the compiler automatically replaces code like this:

Integer i1 = 42;

with the following:

Integer i1 = Integer.valueOf(42);

You know that using == on non-primitive values returns true only if the values on both sides of the == operator refer to the exact same object. (It returns false if you have two different objects, even if those objects have the same value).

So, the question now is, why does this print true:

Integer i1 = 42;
Integer i2 = 42;
System.out.println(i1 == i2);

but why does this print false:

Integer i1 = 1000;
Integer i2 = 1000;
System.out.println(i1 == i2);

The answer is in the way that Integer.valueOf(...); works. This method does not always return a new Integer object - instead, it manages a cache that contains Integer objects with all the values between -128 and 127. If the value you pass into the method is in that range, it will return the pre-created object in the cache. In the first example with the value 42, the variables i1 and i2 will therefore refer to the same Integer object (that comes from the cache). In the second example with the value 1000, you will get two distinct Integer objects, because 1000 is outside of the range of the cache.

[Anant Jagania]

Does autoboxing work the similar way for other primitive wrapper objects? Does caching happen for other wrapper objects like Long, Double, Boolean, Short, Float, Byte?

[Raza Mohd]

@jesper thanks for concrete explaination!

Does caching happen for other wrapper objects like Long, Double, Boolean, Short, Float, Byte?

i have same query as Anant.

[Nikhil Kumar C]

Integer.valueOf(...) does not always return a new Integer object - instead, it manages a cache that contains Integer objects with all the values between -128 and 127.

Is there any specific reason why only integer values between -128 to 127 are being cached?

[raul saini]

Got it, Thank You Every One.

[Henry Wong]

Nikhil Kumar C wrote:
Is there any specific reason why only integer values between -128 to 127 are being cached?

The specification defines the types and the ranges that must be cached. It does not define what should happen to the values of other types, or if they are outside of the required ranges.

The current Sun java implementation caches as required, plus... (1) it also caches long values, which is not required, and (2) there is a switch to allow the user to increase the range (caching values which are not required).

Henry

[Jim Hoglund]

To me it seems logical that the reasons the specification would call for cached
values are the usual - space and speed. On average, the code will run faster
and in less space with the cached primitives.

Jim ... ...