EDIT: OK, OK, I misread. I\'m not comparing an int to an Integer. Duly noted.
My SCJP book says:
When == is used to compare a primitive to a
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.
Note also that newer versions of Java cache Integer
s 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 Integer
s with ==
that will fail for the reasons @dan04 explained.
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);
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
If two Integer objects values are between -128 to 127, this method returns same values. So (c == d) returns true.
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
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.