== and != can only be used with the Integer wrapper when the number is between -127 and 127. Otherwise, the == and != will answer the question "are the references pointing to the same object?" correctly as "false"
This is from K&B's SCJP 6.0 book - I'd highly recommend purchasing it -
...page 246... In order to save memory, two instances of the following wrapper objects (created through boxing), will always be == when their primitive values are the same: ■ Boolean ■ Byte ■ Character from \u0000 to \u007f (7f is 127 in decimal) ■ Short and Integer from -128 to 127 Note: When == is used to compare a primitive to a wrapper, the wrapper will be unwrapped and the comparison will be primitive to primitive. .... [ November 10, 2008: Message edited by: Steven Landers ]
for my understanding i==j does not actually comparing their values but instead it compares the address of where the value 23 was stored in the memory.
sample 1: Integer i = 23; // reference i points to the address where 23 was stored Integer j =23; // since 23 already exist in the memory, make reference j point to that same address in memory.
thats why (i==j) equals to true because i and j points to the same address
sample 2: Integer i = 23; // reference i points the the address where 23 was stored Integer j =new Integer(23);// this time a new Object was created and stored in different address in memory, then make reference j points to that address
so i==j will result to false.
so to get the result as expected you can use the .equals method. [ November 10, 2008: Message edited by: joseph gonzales ]
The answer to your questions is there in Steven's post...
In order to save memory, two instances of the following wrapper objects (created through boxing), will always be == when their primitive values are the same: ......... ......... Short and Integer from -128 to 127
So, in case of Integer i1 = 127; Integer i2 = 127; These are Integer variables created through boxing (ie. without using new operator)...So, as per the rule given above, an == operation on i1 and i2 will be true..
If you change the value of i1 and i2 to 128 or greater, == will return false [ November 10, 2008: Message edited by: Rekha Srinath ]
Joined: Nov 10, 2008
Thanks, Joseph and Rekha.
So my understanding is that like the String pool, an Integer pool also exists, and behaves exactly like the String pool. Am I correct?
Joined: Sep 13, 2008
I don't think you can call it an Integer pool... And I don't know if something like that exists...
Also, note that this specific == rule for Integer created through boxing is valid only for integer values till 127 (and other data types, which Joseph had quoted from K&B). But, in case of String literals, there is no such bound.