Wrappers and primitives comparison:

Hi everyone , extracted this from the API topic from the Tiger's Handbook.

Integer j1 = 2;
Integer j2 = 2;
System.out.println(j1 == j2); // TRUE

Integer k1 = 150;
Integer k2 = 150;
System.out.println(k1 == k2); // FALSE

Integer jj1 = 127;
Integer jj2 = 127;
System.out.println(jj1 == jj2); // TRUE

Do not understand why the results for the 3 comparisons are different since all of them are performing auto-boxing?

Thanks in advance.

Cheers.

huh. weird one. messed with it...

and got...

would like to know more about this. looks like a size constraint at 2^7. feedback anyone?

is there an online source for this? have been googling it some, not finding good stuff yet.

Interesting... weird ...

bit more to this story. ian posted interesting comment on blog. took this insight and expanded orig snippet:

and got...

funky.

Seems like valid values for byte are the only ones this trick works for.

However, trusting on autoboxing for comparing primitive wrappers with = is something you should avoid, since there is ambiguity: which comparison should be used, the autoboxed comparison on the primitive value or the comparison on reference value?

we talked about it here and feel for now that this explains it...

The Integer class keeps a cache of Integer instances representing values from -128 to 127. When references are made with values within this range, the corresponding cached instance is returned, so, for values within this range, == is returning true because the operands are in fact the same instance (from the cache). This is not the case with values outside the cached range. In those cases, the operands are different memory locations, and == evaluates to false.

seems like care needs to be exercised with autoboxing. the possibility of being surprised by this behavior, and the ease with which one may incur an NPE are things to keep in mind.

rob, our conversation about this thus far has us leaning towards use of equals() for wrapper, and/or valueOf(). methinks you are rightin advising others to avoid ==.

looks like autoboxing uses Integer.valueOf to create the wrapper. This method uses a cache of pre-allocated Integer objects for the range -128 to 127. So the same instance is returned on multiple calls to create a wrapper for the same number. Thus the == operator return true since it is the same instance. Here is the code in java.lang.Integer for valueOf:

See this thread...

http://www.coderanch.com/t/251353/java-programmer-SCJP/certification/Boxing-Unboxing

"Mr foo"

Please click on the My Profile link above and change your display name to match JavaRanch's Naming Policy of using your real first and real last names.

Thanks

Mark

Hi
First of all this code will not compile.

Integer j1 = 2;
Integer j2 = 2;

Can you plz expline why & how you are compiling this code.??

Hi ..purujit..

This is possible in jdk1.5

not in earlier versions...

a feature called autoboxing

Regards

[ November 08, 2005: Message edited by: A Kumar ]
[ November 08, 2005: Message edited by: A Kumar ]

Autoboxing is implicit conversion between numeric (also character/boolean? I'm not that familiar with 1.5) primitives and their wrapper classes.

Where in 1.4 and before you had to write Integer i = new Integer(2) or int i = new Integer(2).intValue(), 1.5 does that for you when you write Integer i = 2 or int i = new Integer(2).

Autoboxing is

and some argue that it can be a real stinker.

i've happily used it for stuff like this:

That's basically what it was meant for I think - for storing primitives in collections without the extra effort for explicit transforming between the two.
Which is a real pain, I know...

More generally: autoboxing is meant for code where you need to pass a primitive but an object is expected.
[ November 09, 2005: Message edited by: Rob Spoor ]

Marc, your last name can't be "Foo".

Mark

Marc, your last name can't be "Foo".

Why couldn't it? My local telephone directory has 30 people whose last name is "Foo".

whose last name is "Foo"

calling to mind some funny dialog from a great (imo) movie.

a real pain

ee-yup

comes out of the ResultSet as ints, need to get into the bean as Integers.
[ November 10, 2005: Message edited by: Erick Reid ]

hi,
first fall the code own't compile, as some one said ... this might not be true with 1.5. But why the output would be true.. in this case

Integer i = 2;
Integer j = 3;

Wrapper classes are used to get primitives the advantages of objects...
so, then you need to use .equals method to compare the objects right... then only i.equals(j)) would be true . I would be thankful if someone could explain me how i==j would be true......
thanks in advance
sruthi

hi,
first fall the code own't compile, as some one said ... this might not be true with 1.5. But why the output would be true.. in this case

Integer i = 2;
Integer j = 2; ( 2 instead of 3, in the previous forum i posted it as 3 iam sorry)

Wrapper classes are used to get primitives the advantages of objects...
so, then you need to use .equals method to compare the objects right... then only i.equals(j)) would be true . I would be thankful if someone could explain me how i==j would be true......
thanks in advance
sruthi

Hey Guys -

You've the Integer part of this thing worked out, if you check out section 5.1.7 of the new language spec. you'll find the rest!

hth,

Bert

language spec? we don't need no stinking language spec!

Just to add a point to Ray Horn's views

As suggested by Bert, a piece of info from language spec,

If the value 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.

I assume that explains the behaviour..