This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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:
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 ]
Joined: Sep 10, 2007
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..
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.
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.
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:
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 ]