What exactly does comparing Integers with == do?

EDIT: OK, OK, I misread. I'm not com开发者_如何转开发paring an int to an Integer. Duly noted.

My SCJP book says:

When == is used to compare a primitive to a wrapper, the wrapper will be unwrapped and the comparison will be primitive to primitive.

So you'd think this code would print true:

    Integer i1 = 1; //if this were int it'd be correct and behave as the book says.
    Integer i2 = new Integer(1);
    System.out.println(i1 == i2);

but it prints false.

Also, according to my book, this should print true:

Integer i1 = 1000; //it does print `true` with i1 = 1000, but not i1 = 1, and one of the answers explained why.
Integer i2 = 1000;
System.out.println(i1 != i2);

Nope. It's false.

What gives?

Note also that newer versions of Java cache Integers in the -128 to 127 range (256 values), meaning that:

Integer i1, i2;

i1 = 127;
i2 = 127;
System.out.println(i1 == i2);

i1 = 128;
i2 = 128;
System.out.println(i1 == i2);

Will print true and false. (see it on ideone)

Moral: To avoid problems, always use .equals() when comparing two objects.

You can rely on unboxing when you are using == to compare a wrapped primitive to a primitive (eg: Integer with int), but if you are comparing two Integers with == that will fail for the reasons @dan04 explained.

Integer i1 = 1;
Integer i2 = new Integer(1);
System.out.println(i1 == i2);

When you assign 1 to i1 that value is boxed, creating an Integer object. The comparison then compares the two object references. The references are unequal, so the comparison fails.

Integer i1 = 100;
Integer i2 = 100;
System.out.println(i1 != i2);

Because these are initialized with compile-time constants the compiler can and does intern them and makes both point to the same Integer object.

(Note that I changed the values from 1000 to 100. As @NullUserException points out, only small integers are interned.)

Here's a really interesting test. See if you can figure this out. Why does the first program print true, but the second one false? Using your knowledge of boxing and compiler time analysis you should be able to figure this out:

// Prints "true".
int i1 = 1;
Integer i2 = new Integer(i1);
System.out.println(i1 == i2);

// Prints "false".
int i1 = 0;
Integer i2 = new Integer(i1);
i1 += 1;
System.out.println(i1 == i2);

If you understand the above, try to predict what this program prints:

int i1 = 0;
i1 += 1;
Integer i2 = new Integer(i1);
System.out.println(i1 == i2);

(After you guess, run it and see!)

You're not comparing a primitive to a wrapper. You're comparing two wrappers (reference types). == compares object identity, which returns false because they're different objects.

No, I would not think that code print true, and you answered yourself exactly why.

When == is used to compare a primitive to a wrapper, the wrapper will be unwrapped and the comparison will be primitive to primitive.

and you then went on to compare two Integer references- that is, it compared the memory address of i1 and i2. You wanted either

Integer i1 = 1;
Integer i2 = new Integer(1);
System.out.println(i1.equals(i2));

Or

int i1 = 1;
Integer i2 = new Integer(1);
System.out.println(i1 == i2);

Note that you misread the excerpt you quoted. The excerpt specifically limits it statement to comparisons like these:

int k = 1;
Integer l = new Integer(1);
System.out.println(l == k);

Since Java 5.0, there is automatic boxing and unboxing, meaning that wrappers can be implicitly converted to primitives and vice versa. However, if you compare two Integer objects, you are still comparing two references, and there is nothing that would trigger automatic boxing/unboxing. If that was the case, code written in J2SE 1.4 and prior would break.

Suppose let has have a example

What will be the output of this program code?

public class autoboxing {
public static void main(String a args) {
Integer a = new Integer(127);
Integer b = new Integer(127);
Integer c = 127;
Integer d = 127;
Integer e = new Integer(200);
Integer f = new Integer(200);
Integer g = 200;
Integer h = 200;
System.out.println((a == b) + ' " + (c =-- d) + " " + (e==f)+ " "+ (g == h));

.

When you create an Integer object with a new operator, it returns a new object every time. When you are comparing two reference variables with "==" operator, if two reference variables are referring to two different objects, "==" operator returns false.

So,

(a == b) and (e==f) expressions returns false. Integer class caches values between -128 to 127.

When you are comparing two Integer objects with "==" operator, if those two integer objects are created with autoboxing then value0f(int i) method will be called.

ANSWER: False True False False

Below is the implementation of that method

public static Integer value0f(int i) {
if (i >= IntegerCachedow && i <= IntegerCache.high)
return IntegerCache.cacheli + (-IntegerCachedow));
return new Integer(i);

From the above implementation, below are the conclusions

1. If two Integer objects values are between -128 to 127, this method returns same values. So (c == d) returns true.

2. If two Integer objects values are outside of the range -128 to 127, this method returns different new Integer objects. So, (g == h) returns false

More detail about the method here: https://stackoverflow.com/questions/20897020/why-integer-class-caching-values-in-the-range-128-to-127