1

I found that when x and y are autoboxed to 400the output is Not same but when x and y are autoboxed to 40 they are coming as same.Why??

public class Demo1 {
    public static void main(String args[]) {
         Integer x = 400, y = 400;
         if (x == y)
            System.out.println("Same");
         else
            System.out.println("Not Same");
    }
}
i23
  • 508
  • 2
  • 12
Anil Kumar
  • 348
  • 5
  • 16
  • @Paul - not it isn't. – Stephen C Sep 21 '15 at 12:29
  • this issue here is obviously not autoboxing, but the comparison via `==`. `Object` are usually compared via `equals` –  Sep 21 '15 at 12:29
  • @AbubakkarRangara That is what my doubt is.I know the difference b/w == and equals(). – Anil Kumar Sep 21 '15 at 12:30
  • @StephenC i know the title isn't exactly helpfull with this one. But the topic is just the same. Comparing Objects –  Sep 21 '15 at 12:30
  • 3
    @Paul - no it isn't. This question is about the caching behavior of the primitive wrapper types. Comparing objects is a broader question ... and the answer you proposed as a duplicate isn't even about that. – Stephen C Sep 21 '15 at 12:31
  • 1
    I could not believe this behavior until I tried it. – gefei Sep 21 '15 at 12:33
  • 1
    This may well be duplicated but the duplicates are not good ones for this specific problem (caching specific `Integers`). Voted to reopen. – Bathsheba Sep 21 '15 at 12:35
  • @gefei - It is described in JLS 5.1.7 (http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7) at the end of the section. Complete with a rationale. – Stephen C Sep 21 '15 at 12:36
  • 1
    I agree with @Bathsheba this question is not a duplicate of the ones provided. – NitrogenReaction Sep 21 '15 at 12:37
  • Please open this question! @StephenC sir please take ur time and elaborate, as I'm new to java I will also go through it. – Praneeth Sep 21 '15 at 12:39
  • Sorry ... do you want me to copy an paste the answer from the other question? Please explain what you don't understand. There is no need to elaborate on an Answer that thoroughly answers your question already. – Stephen C Sep 21 '15 at 12:40
  • @Paul Hi paul.At first i too thought that this question is similar too string comparision but Great lord it is not.You read it once again it is the peculiar behaviour of java.Thanks. – Anil Kumar Sep 22 '15 at 11:31
  • 1
    @AnilKumar yeah, sry. Thought it was just that usual BS about comparing objects. I've voted to reopen –  Sep 22 '15 at 11:43

2 Answers2

4

As an optimisation, the JVM caches some Integer references (those from -128 to +127) when it starts up.

So an Integer equal to 40 will refer to one in that cache. That's why two references with value 40 will compare equal: they are both referring to the same cached object.

Since 400 is outside the cached range, an Integer reference set to 400 will not refer to a cached object, so two references with that value will not compare equal.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • 1
    To add to this, == works in the cached case (40 in your example), because both instances x and y refer to the exact same object in the cache, whereas when you create x=400 and y=400, they refer to different objects in memory. – Jamie Sep 21 '15 at 12:36
2

This is because of the Java Integer cache. When a number is within the cache the reference is intilized to one from the cache instead of making a new object. In your case, 40 is within the cache so the object references are the same, but 400 is outside of the cache so the objects are not the same reference.See this answer.

Community
  • 1
  • 1
NitrogenReaction
  • 336
  • 1
  • 9