Wrappers and primitives comparison:

[Marc Foo]

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.

[Anonymous]

huh. weird one. messed with it...

    for (int i = 0; i < 150; i++) {
      Integer i1 = i;
      Integer i2 = i;
      System.out.println(i + ":" + (i1 == i2));
    }

and got...

125:true
126:true
127:true
128:false
129:false
130:false

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

[Anonymous]

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

[Lakshmanan Arunachalam]

Interesting... weird ...

[Anonymous]

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

    for (int i = -130; i < 130; i++) {
      Integer i1 = i;
      Integer i2 = i;
      System.out.println(i + ":" + (i1 == i2));
    }

and got...

-130:false
-129:false
-128:true
-127:true
...
126:true
127:true
128:false
129:false

funky.

[Rob Spoor]

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?

[Anonymous]

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.

[Anonymous]

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 ==.

[Ray Horn]

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:

     public static Integer valueOf(int i) {
final int offset = 128;
if (i >= -128 && i <= 127) { // must cache 
    return IntegerCache.cache[i + offset];
}
        return new Integer(i);
    }
 

[marc weber]

See this thread...

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

[Mark Spritzler]

"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

[Purujit Saha]

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.??

[A Kumar]

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 ]

[Rob Spoor]

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).

[Anonymous]

Autoboxing is

and some argue that it can be a real stinker.

i've happily used it for stuff like this:

public void doStuff(List<Integer> integers) {
  for (Integer integer : integers) {
    _doStuff(integer);
  }
}
private void _doStuff(int i) {
  // stuff
}

[Rob Spoor]

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 ]

[Mark Spritzler]

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

Mark

[Paul Clapham]

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

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

[Anonymous]

whose last name is "Foo"

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

[Anonymous]

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 ]

[sruthi gundu]

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

[sruthi gundu]

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

[Bert Bates]

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

[Anonymous]

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

[Cheenu Subramanian]

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..