Unexpected result when comparing ints

Question

Possible Duplicate:
Integer wrapper objects share the same instances only within the value 127?
How != and == operators work on Integers in Java?

I tried to compare two ints with the following cases and got unexpected results

when I did the following, @@@ was printed.

 class C {
   static Integer a = 127;
   static Integer b = 127;
   public static void main(String args[]){
   if(a==b){
      System.out.println("@@@"); 
   }
   }
 }

when I did the following, @@@ was not printed.

 class C {
   static Integer a = 145;
   static Integer b = 145;
   public static void main(String args[]){
   if(a==b){
      System.out.println("@@@"); 
   }
   }
 }

Can anyone tell me what could be the reason.

possible duplicate of [Integer wrapper objects share the same instances only within the value 127?](http://stackoverflow.com/questions/5117132/integer-wrapper-objects-share-the-same-instances-only-within-the-value-127) and [New Integer vs valueOf](http://stackoverflow.com/questions/2974561) and [Inconsistent behavior on java's ==](http://stackoverflow.com/questions/1148805) and [Integer wrapper objects share the same instances only within the value 127?](http://stackoverflow.com/questions/5117132) and... — Tomasz Nurkiewicz, Aug 30 '12 at 21:09
More details if you are interested http://vanillajava.blogspot.co.uk/2012/01/surprising-results-of-autoboxing.html — Peter Lawrey, Aug 30 '12 at 21:20

Fabian Barney · Accepted Answer · 2012-08-31T08:44:36.657

7

You're comparing the objects' identities. For values lower than 128 the Integer class caches its objects. That's why it is equal in the first example. The other example is with higher values that are not cached.

As @niklon pointed out there is also a lower border of -128 for caching.

Upper border can be adjusted with a VM arg -Djava.lang.Integer.IntegerCache.high=4711.

Further reading in Peter's interesting blog post: http://vanillajava.blogspot.co.uk/2012/01/surprising-results-of-autoboxing.html

edited Aug 31 '12 at 08:44

answered Aug 30 '12 at 21:11

Fabian Barney

14,219
5
40
60

Does that happen with every other wrapper class too? – Phani Rahul Aug 30 '12 at 21:12
1

By the way, the lower bound for Integer cacheing is -128. – niklon Aug 30 '12 at 21:12
1

@niklon, This is an implementation detail. The [Javadoc](http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#valueOf%28int%29) says "This method will always cache values in the range -128 to 127, inclusive, **and may cache other values outside of this range.**" – Mike Samuel Aug 30 '12 at 21:14
In fact you can set the upper border to another custom value with a vm arg I think. – Fabian Barney Aug 30 '12 at 21:17
@PhaniRahul `Long` and `Short` have caching, too. – Fabian Barney Aug 30 '12 at 21:20

score 5 · Answer 2 · answered Aug 30 '12 at 21:09

5

You're not comparing ints, you're comparing objects for reference equality. Use .equals, or use type int instead of Object.

answered Aug 30 '12 at 21:09

Mike Samuel

118,113
30
216
245

1

/Then why is it printing "@@@" in the first case..? – Rookie Aug 30 '12 at 21:11
2

@Raghav, because many versions of Java [memoize small `Integer`s](http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#valueOf%28int%29): "This method will always cache values in the range -128 to 127, inclusive, and may cache other values outside of this range." – Mike Samuel Aug 30 '12 at 21:12

score 1 · Answer 3 · answered Aug 30 '12 at 21:10

Here you are using Integer objects as opposed to int primitives. Hence, you should compare the two instances with .equals(...) as opposed to ==. If you used the primitive type instead, you would use ==.

It is important to note that, when dealing with objects, == compares the references of the two objects, not the actual values - so it may return seemingly strange results at times.

score 1 · Answer 4 · answered Aug 30 '12 at 21:12

1

Use if(a.equals(b)) and do not use == to compare Objects that are subclasses of Object class.

== operator is just for primitive types like int,long, etc.

answered Aug 30 '12 at 21:12

Mehdi

4,396
4
29
30

Unexpected result when comparing ints

4 Answers4