• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Does autoboxing take place automatically for ==

 
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 2023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 2023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


prints
i2 == list.get(1) (list, autoboxing) is true
 
Firas Zuriekat
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Now it's very clear....Also, if we remember it behaves like strings...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic