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));
Related
This question already has answers here:
How do I compare two Integers? [duplicate]
(9 answers)
Closed 7 years ago.
I noticed that the following code returns false
Integer a = 600;
Integer b = 600;
System.err.println(a == b);
but this one
int a = 600;
int b = 600;
System.err.println(a == b);
returns true
can anybody explain?
The most important thing to know is the values up to 128 are cached, and the JVM gives you the same objects,for that the reference comparison works. Above 128 it creates a new instance.
For more info go to javadoc of Integer.valueOf(int) (which is what happens behind the scene)
This behavior is correct, in java == compares object references, it checks to see if the two operands point to the same object (not equivalent objects, the same object).
so your 1st example:
Integer a = 600;
Integer b = 600;
System.err.println(a == b);
you are asking java to tell you if the have the same reference, which is false
in the example 2:
a and b are primitives, and you are asking java to tell you if the have the same value, which is True
Jeff had already an answer for this
This question already has answers here:
Integer wrapper class and == operator - where is behavior specified? [duplicate]
(2 answers)
Closed 8 years ago.
I have been playing with == in wrapper classes. There's some weird thing that I encountered.
Integer i1 = 3;
Integer i2 = 3;
if(i1 != i2)
{
System.out.println("i1 and i2 are not equal"); // if condition returns false in this case
}
which is working perfectly fine as far as my knowledge is concerned.
whereas, If I instantiate wrapper with
Integer i1 = 1000;
Integer i2 = 1000;
if(i1 != i2)
{
System.out.println("i1 and i2 are not equal"); // if condition returns true in here
}
Then I am getting confused with the dual behavior of JVM with respect to the different values assigned to wrapper.
Why is this happening so? Please share your thought on this.
Thanks
You need to use !i1.equals(i2)
This question already has answers here:
Boxed Primitives and Equivalence
(4 answers)
Closed 9 years ago.
class Demo{
public static void main(String[] args) {
Integer i = Integer.valueOf(127);
Integer j = Integer.valueOf(127);
System.out.println(i==j);
Integer k = Integer.valueOf(128);
Integer l = Integer.valueOf(128);
System.out.println(k==l);
}
}
The first print statement prints true whereas the second one prints false.Why?
Please explain in detail.
It is because Integer caching.
From java language specification 5.1.7
If the value p being boxed is true, false, a byte, or a char in the range
\u0000 to \u007f, or an int or short number between -128 and 127 (inclusive),
then let r1 and r2 be the results of any two boxing conversions of p.
It is always the case that r1 == r2.
Ideally, boxing a given primitive value p, would always yield an identical reference.
Integer i = Integer.valueOf(127);
Integer j = Integer.valueOf(127);
Both i and j point to same object. As the value is less than 127.
Integer k = Integer.valueOf(128);
Integer l = Integer.valueOf(128);
Both k & l point to different objects. As the value is greater than 127.
As, you are checking the object references using == operator, you are getting different results.
Update
You can use equals() method to get the same result
System.out.println(i.equals(j));//equals() compares the values of objects not references
System.out.println(k.equals(l));//equals() compares the values of objects not references
Output is
true
true
== operator checks the actual object references.
equals() checks the values(contents) of objects.
Answer to comment
You have,
Integer i = Integer.valueOf(127);
Here new object is created & reference is assigned to i
Integer j = Integer.valueOf(127); //will not create new object as it already exists
Due to integer caching (number between -128 to 127) previously created object reference is assigned to j, then i and j point to same objects.
Now consider,
Integer p = Integer.valueOf(127); //create new object
Integer q = Integer.valueOf(126); //this also creates new object as it does not exists
Obviously both checks using == operator and equals() method will result false. As both are different references and have different vales.
i==j
is true for values between -128 and 127 due to integer caching.
From language spec
If the value p being boxed is true, false, a byte, or a char in the range \u0000 to \u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.
Integer i = Integer.valueOf(127); // new object
Integer j = Integer.valueOf(127); //cached object reference
Integer k = Integer.valueOf(128); // new object
Integer l = Integer.valueOf(128); // new object
So i and j are pointing to same reference because of value 127.
Where as k and l pointing to difference references, because their value >127
There is a reason mentioned in docs for this behaviour:
The behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might
valueOf returns an Integer Object. Integer is a wrapper class for int. For your case,
Integer == Integer compares the actual object reference, where int == int will compare the values.
As already stated, values -128 to 127 are cached, so the same objects are returned for those.
If outside that range, separate objects will be created so the reference will be different.
You fix it by following way if you want same result for your both cases:
Make the types int
Cast the types to int or
Use .equals()
This question already has answers here:
Integer wrapper objects share the same instances only within the value 127? [duplicate]
(5 answers)
Closed 10 years ago.
Someone postulated in some forum thread that many people and even experienced Java Developers wouldn't understand the following peace of Java Code.
Integer i1 = 127;
Integer i2 = 127;
System.out.println(i1++ == i2++);
System.out.println(i1 == i2);
As a person with some interest in Java I gave it my thoughts and came to the following result.
System.out.println(i1++ == i2++);
// True, since we first check for equality and increment both variables afterwards.
System.out.println(i1 == i2);
// True again, since both variables are already incremented and have the value 128
Eclipse tells me otherwise. The first line is true and the second is false.
I really would appreciate an explanation.
Second question. Is this Java specific or does this example hold for example for the C based languages, too?
Integer i1 = 127;
Integer i2 = 127;
System.out.println(i1++ == i2++);
// here i1 and i2 are still 127 as you expected thus true
System.out.println(i1 == i2);
// here i1 and i2 are 128 which are equal but not cached
(caching range is -128 to 127),
In case 2 if you use equals() it'd return true as == operator for integers only works for cached values. as 128 is out of cache range the values above 128 will not be cached, thus youhave to use equals() method to check if two integer instances above 127 are true
TEST:
Integer i1 = 126;
Integer i2 = 126;
System.out.println(i1++ == i2++);// true
System.out.println(i1 == i2); //true
Integer i1 = 126;
Integer i2 = 126;
System.out.println(i1++ == i2++);// true
System.out.println(i1.equals(i2)); //true
Integer i1 = 128;
Integer i2 = 128;
System.out.println(i1++ == i2++);// false
System.out.println(i1==i2); //false
Integer i1 = 128;
Integer i2 = 128;
System.out.println(i1++.equals(i2++));// true
System.out.println(i1.equals(i2)); //true
As explained this is due to Integer caching. For fun, you can run the program with the following JVM option:
-XX:AutoBoxCacheMax=128
and it will print true twice (option available on hostpot 7 - not necessarily on other JVMs).
Note that:
this is JVM specific
the modified behaviour is compliant with the JLS which says that all values between -128 and +127 must be cached but also says that other values may be cached.
Bottom line: the second print statement is undefined in Java and can print true or false depending on the JVM implementation and/or JVM options used.
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]