aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Does autoboxing take place automatically for == Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Does autoboxing take place automatically for ==" Watch "Does autoboxing take place automatically for ==" New topic
Author

Does autoboxing take place automatically for ==

Firas Zuriekat
Ranch Hand

Joined: May 09, 2006
Posts: 144
Given,



What's the possible output and why?

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 ]
wise owen
Ranch Hand

Joined: Feb 02, 2006
Posts: 2023
5.1.7 Boxing Conversion

Two instances of the Boolean, Byte, Character from \u0000 to \u007f (7f is 127 in decimal), and Short and Integer from -128 to 127 objects will always be == when their primitive values are the same.
Firas Zuriekat
Ranch Hand

Joined: May 09, 2006
Posts: 144
In my case the value is 18 which is within the range -128 to 127 you mentioned above. Therefore, the Integer wrapper will pass the == test with its primitive value of 18.

This should result in "truetrue". But the correct answer is "falsetrue". Why is that?
wise owen
Ranch Hand

Joined: Feb 02, 2006
Posts: 2023
If

Gen<Integer> i1=new Gen<Integer>(18); // Line 1
Gen<Integer> i2=new Gen<Integer>(18)); //Line 2

Then
i1.get()== i2.get() is true.
raj abi
Greenhorn

Joined: Jun 11, 2006
Posts: 2
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.
Nikhil Goel
Ranch Hand

Joined: Jul 11, 2003
Posts: 32
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
Firas Zuriekat
Ranch Hand

Joined: May 09, 2006
Posts: 144
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.

OUTPUT:

i==Integer
-129==Integer
I equals i
Byte==-128
[ June 12, 2006: Message edited by: Firas Zureikat ]
Lukas Stephienn
Ranch Hand

Joined: Dec 23, 2005
Posts: 60
Hi guys.

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

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

the result would by true;

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.

Does this make sense for you?


SCJP 5.0 (91%), SCBCD 1.3 (94%), SCWCD 1.4 (88%)
Anupama Ponnapalli
Ranch Hand

Joined: Jun 12, 2006
Posts: 66
Agreed. From Sun's Java tech tips:

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
Anupama Ponnapalli
Ranch Hand

Joined: Jun 12, 2006
Posts: 66


prints
i2 == list.get(1) (list, autoboxing) is true
Firas Zuriekat
Ranch Hand

Joined: May 09, 2006
Posts: 144
Now it's very clear....Also, if we remember it behaves like strings...
 
 
subject: Does autoboxing take place automatically for ==