A) Compilation fails due to an error on Line 1 B) Compilation Fails due to an error on Line 2 C) Compilation Fails due to an error on Line 3 D) Compilation Fails due to an error on Line 4 E) Exception at runtime F) prints falsetrue H) prints falsefalse I) Prints truetrue
Why is the answer F? Doesn't autoboxing for (i2.get()==i1.get()) takes place? I mean the get() retuns an Integer that is unboxed for performing the ==, right?
Also, what about the Integer pool? Isn't it making the object returned form i2.get() to point to the same exact object returned from i1.get() in order to save precious memory like the String pool does? [ June 11, 2006: Message edited by: Firas Zureikat ]
I think the answer is "falsetrue" and not "truetrue" because the unboxing does not happen when Integer object is retrieved from the Generics object. The initial value was boxed and put inside, but is present now as an object. So, it behaves like any other object comparison for "==" with references needed to be equal. Please correct me if am wrong.
I agree with raj . Answer has to be falsetrue reason being the objecj references are different . '==' is used for comparing object references and both of them have different . Even if you look at http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7 what is clearly mentions is '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.'
If you decipher the statement right it says 'result of two boxing conversions' here in this case there are no 2 boxing conversions only one . The next one is itself an object no need for boxing
Hope it helps
Joined: May 09, 2006
What do you mean? The following is not only outside the range you specified above but uses unsymmetrical boxing on each side of == and they are all true:
One side uboxing once while the other is a primitive. So no symmetry.
i==Integer -129==Integer I equals i Byte==-128 [ June 12, 2006: Message edited by: Firas Zureikat ]
Answer falsetrue is correct although numbers are in one byte range. It's because using == operator, when on both sides are Number objects there is no unboxing, just simple reference equality. If we write
but if we replace creation of either i1 or i2 on new Integer(18); result will be false;
It's almost same as in Strings. Java has pool of wrapper objects (only from -128 to 127) and when we create wrapper instance (without using new) we take it from pool. So if we want to take wrapper which is in pool already, we have two references to the same object.
But when we use new operator we are sure that new object is created.
Autoboxing is guaranteed to return the same object for integral values in the range [-128, 127], but an implementation may, at its discretion, cache values outside of that range. It would be bad style to rely on this caching in your code.
In fact, testing for object equality using == is, of course, not what you normally intend to do. This cautionary example is included in this tip because it is easy to lose track of whether you are dealing with objects or primitives when the compiler makes it so easy for you to move back and forth between them.
Also, here is a simple example:
The output is: i1 == i2 (autoboxing) is true i3 == i4 (new object) is false i2 == i3 (combination) is false list.get(0) == list.get(1) is true i5 == i6 (autoboxing, > range) is false
Joined: Jun 12, 2006
prints i2 == list.get(1) (list, autoboxing) is true
Joined: May 09, 2006
Now it's very clear....Also, if we remember it behaves like strings...