Q on Integer()

[Shaily Sharma]

class test1 {
public static void main(String[] args) {
test1 inst_test = new test1();
int i1 = 2000;
int i2 = 2000;
int i3 = 2;
int i4 = 2;
Integer Ithree = new Integer(2); // 1
Integer Ifour = new Integer(2); // 2
System.out.println( Ithree.equals( Ifour ));
inst_test.method( i3 , i4 );
inst_test.method( i1 , i2 ); //3
}
public void method( Integer i , Integer eye ) {
System.out.println(i == eye );
}
}

output is true true false.
Why does it return false for i1 and i2?
2000 falls within range for int/Integer (32 bit/4 byte)

Thanks in advance

[ahmed yehia]

Two Integers with the value between -128 and 127 are considered true comparing with == operator.

[Bridget Kennedy]

There are a couple of things going on here. First of all, keep in mind the difference between == and .equals(). Try putting this line in the method routine to demonstrate the difference:

  System.out.println( i.equals(eye) );  

Next, when int(s) are passed to method(Integer, Integer), you have an occurrence of autoboxing
The int(s) are automatically converted to Integer objects by the compiler. The reason the test case runs as it does can be explained in the "Immutable Objects" section:

Normally, when the primitive types are boxed into the wrapper types, the JVM allocates memory and creates a new object. But for some special cases, the JVM reuses the same object.

The following is the list of primitives stored as immutable objects:

boolean values true and false
All byte values
short values between -128 and 127
int values between -128 and 127
char in the range \u0000 to \u007F

The == check evaluates if the two objects are the same object. Autoboxing - or instantiating an Integer by passing an int - of any int value 2 will result in a reference to a single immutable Integer object. In the case of 2000, the autoboxing created two different objects - both having an int value of 2000, but entirely different objects on the heap.
[ September 25, 2007: Message edited by: Bridget Kennedy ]

[Shaily Sharma]

thanks for the replies!
I am not clear abt:

"The == check evaluates if the two objects are the same object. Autoboxing of any int value 2 will result in a reference to a single immutable Integer object. In the case of 2000, the autoboxing created two different objects - both having an int value of 2000, but entirely different objects on the heap. "

Does it mean range of an Integer is reduced in autoboxing process?
from 4 bytes to 1byte?
And why this results in immutable object?
as far as I cud recall the default Integer() object isnt
immutable..

[Collins Mbianda]

Hi !!!

By Java Language Specification

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

[Corey McGlone]

Originally posted by Shaily Sharma:
Does it mean range of an Integer is reduced in autoboxing process?
from 4 bytes to 1byte?

No, that doesn't mean the range is reduced. When you perform autoboxing, you're going to get an Integer object with the same value as the int primitive - that's guaranteed.

However, for int values between -128 and 127, you won't necessarily get a "new" object - the JVM may opt to reuse an existing object with the same value, if one exists.

And why this results in immutable object?
as far as I cud recall the default Integer() object isnt
immutable..

Integer objects are immutable. All of 'em. Regardless of value.
[ September 25, 2007: Message edited by: Corey McGlone ]

[Jesper de Jong]

Originally posted by Ahmed Yehia:
Two Integers with the value between -128 and 127 are considered true comparing with == operator.

But not always - only if you got those two Integers by calling Integer.valueOf(...) or by autoboxing. (Autoboxing calls Integer.valueOf(...) behind the scenes). If you explicitly create two Integer objects with 'new Integer(...)', then == will return false, even if the value is in the range -128...127.

// Autoboxing
Integer a = 23;
Integer b = 23;
 
// This prints: true
System.out.println(a == b);
 
// Explicitly creating Integer objects
Integer c = new Integer(23);
Integer d = new Integer(23);
 
// This prints: false
System.out.println(c == d);

Note that == checks if two variables point to the same object (it only checks if the references are equal, not if the content of the objects that are referred to are equal). If you explicitly create new Integer objects, then you have two different objects, so == will return false.

So why then does it return true when you get the Integer objects via Integer.valueOf(...) or via autoboxing?

The way this works behind the scenes is this: The method Integer.valueOf(...) maintains a pool of Integer objects, with the values in the range -128...127. If you call Integer.valueOf(...) with a value in the range, then the method returns the corresponding Integer object from the pool instead of creating a new Integer object with the specified value. This is done as an optimization, so that for commonly used values it's not necessary to create new Integer objects.

So if you do this:

Integer a = 23;
Integer b = 23;

then a and b are referring to the exact same Integer object - the one that Integer.valueOf(...) returned from its pool, and therefore a == b returns true.
[ September 25, 2007: Message edited by: Jesper Young ]