This question already has answers here:
Weird Integer boxing in Java
(12 answers)
Closed 7 years ago.
I know int range is -2147483648 to +2147483647 but here I'm getting output as true and false. Why? Actually i1 and i2 point to the same object, so output is true. I can understood but i3 and i4 also pointing to same object but I got output as false. Why?
public class MainClass {
public static void main(String[] args) {
Integer i1 = 127;
Integer i2 = 127;
System.out.println(i1 == i2);
Integer i3 = 128;
Integer i4 = 128;
System.out.println(i3 == i4);
}
}
the output is
true
false
why output should be like this?
Because you are using Integer object. For Integer object, values in between -128 to 127 are pooled
The problem is the difference between == and equals. == just tests to see if two Integer variables point to the same object, which could be either true or false depending on the implementation of your JVM. equals actually tests to see if they hold the same value. So in this case, you'll want to use equals:
// ...
System.out.println(i1.equals(i2));
// ...
System.out.println(i3.equals(i4));
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How != and == operators work on Integers in Java?
Integer i1 = 1000;
Integer i2 = 1000;
if(i1 == i2) is return false. Exactly what it happen how it is checking this condition here?
if i assign lesser than 128 in both i1 and i2 if condition is true. How object is created here, it is comman for all the values or different?
Could someone clarify this scenario.
if i assign lesser than 128 in both i1 and i2 if condition is true
Yes this happens because for that range Java uses flyweight pattern and caches Integer objects so you get backed the cached version and == works
This is possible as Integer objects are immutable and the caching is only for the range [-128,127]
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Wrapper class and == operator
It seems as if object equality operator for wrapper classes produces different results depending on whether the wrapped value is in byte range or not. Here is a code snippet to demonstrate this behavior:
System.out.println("smaller than byte");
Integer i1 = 1;
Integer i2 = 1;
if (i1 == i2) System.out.println("same");
if (i1 != i2) System.out.println("not same");
System.out.println("larger than byte");
Integer i3 = 128;
Integer i4 = 128;
if (i3 == i4) System.out.println("same");
if (i3 != i4) System.out.println("not same");
produces the following output:
smaller than byte
same
larger than byte
not same
Note: I got this output on HotSpot (build 1.6.0_24-b07) on linux. Same happens for Long and probably Short (haven't tested it though).
Note: Same output on other HotSpot builds under linux
Can anyone explain it?
Small edit, just to make it slightly more interesting:
Adding
if (i3 <= i4 && i3 >= i4) System.out.println("same after all...");
in the end, prints "same after all...".
That's correct. The JVM will "cache" and reuse Integer instances when autoboxing small values.
See Java Language Specification Section 5.1.7 Boxing Conversion:
If the value p 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.
When comparing Integers using <, >, <= and >= the values are un-boxed as opposed to != and ==.
Integers between -127 and 127 are 'cached', so they return same reference, which means i1 and i2 point to same object.
So I was asked this question today.
Integer a = 3;
Integer b = 2;
Integer c = 5;
Integer d = a + b;
System.out.println(c == d);
What will this program print out? It returns true. I answered it will always print out false because of how I understood auto (and auto un) boxing. I was under the impression that assigning Integer a = 3 will create a new Integer(3) so that an == will evaluate the reference rather then the primitive value.
Can anyone explain this?
Boxed values between -128 to 127 are cached. Boxing uses Integer.valueOf method, which uses the cache. Values outside the range are not cached and always created as a new instance. Since your values fall into the cached range, values are equal using == operator.
Quote from Java language specification:
If the value p 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.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.7
This is what is really happening:
Integer c = Integer.valueOf(5);
Integer d = Integer.valueOf(a.intValue() + b.intValue());
Java maintains a cache of Integer objects between -128 and 127. Compare with the following:
Integer a = 300;
Integer b = 200;
Integer c = 500;
Integer d = a + b;
System.out.println(c == d);
Which should print false.
It's because some of the (auto-boxed) Integers are cached, so you're actually comparing the same reference -- this post has more detailed examples and an explanation.
Caching happens outside of autoboxing too, consider this:
Integer a = 1;
Integer b = new Integer(1);
Integer c = Integer.valueOf(1);
System.out.println(a == b);
System.out.println(b == c);
System.out.println(c == a);
this will print:
false
false
true
Generally you want to stay away from == when comparing Objects
I'm a bit confused about the way Java treats == and equals() when it comes to int, Integer and other types of numbers. For example:
Integer X = 9000;
int x = 9000;
Short Y = 9000;
short y = 9000;
List<Boolean> results = new ArrayList<Boolean>();
// results.add(X == Y); DOES NOT COMPILE 1)
results.add(Y == 9000); // 2)
results.add(X == y); // 3)
results.add(X.equals(x)); // 4)
results.add(X.equals(Y)); // 5)
results.add(X.equals(y)); // 6)
System.out.println(results);
outputs (maybe you should make your guess first):
[true, true, true, false, false]
That X == Y does not compile is to be expected, being different objects.
I'm a little surprised that Y == 9 is true, given that 9 is by default an int, and given that 1) didn't even compile. Note that you can't put an int into a method expecting a Short, yet here they are equal.
This is surprising for the same reason as two, but it seems worse.
Not surprising, as x is autoboxed to and Integer.
Not surprising, as objects in different classes should not be equal().
What?? X == y is true but X.equals(y) is false? Shouldn't == always be stricter than equals()?
I'd appreciate it if anyone can help me make sense of this. For what reason do == and equals() behave this way?
Edit: I have changed 9 to 9000 to show that this behavior is not related to the any unusual ways that the integers from -128 to 127 behave.
2nd Edit: OK, if you think you understand this stuff, you should consider the following, just to make sure:
Integer X = 9000;
Integer Z = 9000;
short y = 9000;
List<Boolean> results = new ArrayList<Boolean>();
results.add(X == Z); // 1)
results.add(X == y); // 2)
results.add(X.equals(Z)); // 3)
results.add(X.equals(y)); // 4)
System.out.println(results);
outputs:
[false, true, true, false]
The reason, as best as I understand it:
Different instance, so different.
X unboxed, then same value, so equal.
Same value, so equal.
y cannot be boxed to an Integer so cannot be equal.
(small) Integer instances are cached, so the invariant x == y is holded for small instances (actually -127 +128, depends on JVM):
Integer a = 10;
Integer b = 10;
assert(a == b); // ok, same instance reused
a = 1024;
b = 1024;
assert(a == b); // fail, not the same instance....
assert(a.equals(b)); // but same _value_
EDIT
4) and 5) yield false because equals check types: X is an Integer whereas Y is a Short. This is the java.lang.Integer#equals method:
public boolean equals(Object obj) {
if (obj instanceof Integer) {
return value == ((Integer)obj).intValue();
}
return false;
}
The reason for
X == y
being true has to do with binary numeric promotion. When at least one operand to the equality operator is convertible to a numeric type, the numeric equality operator is used. First, the first operand is unboxed. Then, both operands are converted to int.
While
X.equals(y)
is a normal function call. As has been mentioned, y will be autoboxed to a Short object. Integer.equals always returns false if the argument is not an Integer instance. This can be easily seen by inspecting the implementation.
One could argue that this is a design flaw.
The morale of the story:
Autoboxing/unboxing is confusing, as is type promotion. Together, they make for good riddles but horrendous code.
In practice, it seldom makes sense to use numeric types smaller than int, and I'm almost inclined to configure my eclipse compiler to flag all autoboxing and -unboxing as an error.
Your problem here is not only how it treats == but autoboxing... When you compare Y and 9 you are comparing two primitives that are equal, in the last two cases you get false simply because that's how equals work. Two objects are equal only if they are of the same kind and have the same value.
When you say in "X.equals(y)" you are telling it to do Integer.equals(Short) and looking at the implementation of Integer.equals() it will fail:
public boolean equals(Object obj) {
if (obj instanceof Integer) {
return value == ((Integer)obj).intValue();
}
return false;
}
Because of autoboxing the last two will result in the same failure as they will both be passed in as Shorts.
Edit: Forgot one thing... In the case of results.add(X == y); it will unbox X and do (X.intValue() == y) which happens to be true as well as 9 == 9
This automatic conversion is called autoboxing.
I remember a good practice for overriding "equal(object obj)" is of first checking the type of the parameter passed in. So perhap this causes X.equals(Y) to be false. You might check the souce code to dig out the truth :)
A bit more detail on how autoboxing works and how "small" valued Integer objects are cached:
When a primitive int is autoboxed into an Integer, the compiler does that by replacing the code with a call to Integer.valueOf(...). So, the following:
Integer a = 10;
is replaced by the compiler with the following:
Integer a = Integer.valueOf(10);
The valueOf(...) method of class Integer maintains a cache that contains Integer objects for all values between -127 and 128. If you call valueOf(...) with a value that's in this range, the method returns a pre-existing object from the cache. If the value is outside the range, it returns a new Integer object initialized with the specified value. (If you want to know exactly how it works, lookup the file src.zip in your JDK installation directory, and look for the source code of class java.lang.Integer in it.)
Now, if you do this:
Integer a = 10;
Integer b = 10;
System.out.println(a == b);
you'll see that true is printed - but not because a and b have the same value, but because a and b are referring to the same Integer object, the object from the cache returned by Integer.valueOf(...).
If you change the values:
Integer a = 200;
Integer b = 200;
System.out.println(a == b);
then false is printed, because 200 is outside the range of the cache, and so a and b refer to two distinct Integer objects.
It's unfortunate that == is used for object equality for value types such as the wrapper classes and String in Java - it's counter-intuitive.
Java will convert an Integer into an int automatically, if needed. Same applies to Short. This feature is called autoboxing and autounboxing. You can read about it here.
It means that when you run the code:
int a = 5;
Integer b = a;
System.out.println(a == b);
Java converts it into:
int a = 5;
Integer b = new Integer(a);
System.out.println(a == b.valueOf());