This question already has answers here:
Inconsistent behavior on java's ==
(7 answers)
How != and == operators work on Integers in Java? [duplicate]
(5 answers)
Closed 9 years ago.
With the following:
String a = new String("test");
String b = "test";
System.out.println(a == b); //false
We get false, since String a is an object, so a points to a different location in memory than the string literal, b. I wanted to see how this worked for int and Integer:
Integer x = new Integer(5);
int y =5;
System.out.println(x == y); //true
I though that x.equals(y) would be true, but x == y would be false as it is in the case with Strings. I understand that we compare ints with ==, but I figured that comparing an int to an Integer would be different. Why is this not the case?
I assume that in this case using == won't work for comparing references, so how would we do it (not sure if this is practical, but I'd like to know)?
Because of boxing and unboxing in java
Converting an int to an Integer, a double to a Double, and so on. If
the conversion goes the other way, this is called unboxing.
Autoboxing/unboxing is a pure convenience feature that allows you to assign values of a primitive type a reference of a wrapper class and vice versa, with the compiler automatically adding the code to convert between the two.
Boxing and unBoxing and SEE HERE ALSO
Related
This question already has answers here:
Java: Integer equals vs. ==
(7 answers)
How can I properly compare two Integers in Java?
(10 answers)
Closed 4 years ago.
Consider:
Integer i = 11;
Integer j = 11;
Integer h = 10000;
Integer k = 10000;
System.out.println((i==j));
System.out.println((i.equals(j)));
System.out.println((h==k));
System.out.println((h.equals(k)));
The output is:
true
true
false
true
Actually for h==k, it should also give true. What is the explanation?
Because == checks object references while equals checks actual values. They are not guaranteed to yield the same result.
In some cases they do give the same result, but that's because your JVM is interning some of the Integer objects. Meaning, it maintains a cache of integer objects. So for example if you ask for an Integer value of 10, it might return the same object instance. But there are no guarantees as to which values would be interned. So it is always advisable to use equals instead of relying on ==.
This question already has answers here:
Why does the behavior of the Integer constant pool change at 127?
(4 answers)
Why is 128==128 false but 127==127 is true when comparing Integer wrappers in Java?
(8 answers)
How does auto boxing/unboxing work in Java?
(4 answers)
Closed 4 years ago.
Integer x1 = Integer.parseInt("4");
Integer y1 = Integer.parseInt("4");
Integer x2 = Integer.parseInt("444");
Integer y2 = Integer.parseInt("444");
System.out.println(x1==y1); // true
System.out.println(x2==y2); // false ???
Integer a1 = Integer.valueOf("4");
Integer b1 = Integer.valueOf("4");
Integer a2 = Integer.valueOf("444");
Integer b2 = Integer.valueOf("444");
System.out.println(a1==b1); // true
System.out.println(a2==b2); // false
I understand why the third and fourth output print true and false. This is because valueOf returns an object, and wrapper classes cache objects that have values in the range of -128 to 127. If valueOf is passed any value in that range, it should reuse the object in the cache. Otherwise, it will create a new object.
Now, why does the second output print out false? I thought parseInt returns a primitive, not an object like valueOf does.
I thought parseInt returns a primitive, not an object like valueOf does.
parseInt returns an int but you assign it to an Integer variable, which causes auto-boxing. Since an int whose value is 444 is being auto-boxed two times, each time a new Integer instance is created (since the Integer cache cannot be used for that value), so comparing them with == returns false.
If you'll assign the output of parseInt to an int, the comparisons will return true in both cases:
int x1 = Integer.parseInt("4");
int y1 = Integer.parseInt("4");
int x2 = Integer.parseInt("444");
int y2 = Integer.parseInt("444");
System.out.println(x1==y1); // true
System.out.println(x2==y2); // true
This question already has answers here:
Java: Integer equals vs. ==
(7 answers)
Closed 8 years ago.
Please can you explain the below behaviour.
public class EqAndRef {
public static void main(String[] args) {
Integer i = 10;
Integer j = 10;
Double a = 10D;
Double b = 10D;
System.out.println(i.equals(j));
System.out.println(i == j);
System.out.println(a.equals(b));
System.out.println(a == b);
}
}
Output on jdk 6
true
true
true
false
why a==b is false and i==j not false?
The Integers i and j are constructed (via auto boxing) from integer literals from the range –128 to 127 and thus are guaranteed to be pooled by the JVM so the same object (see flyweight pattern) is used for them. Hence, they compare identical by object references.
For the Doubles a and b on the other hand, no such pooling guarantee exists and, in your case, you got two different objects that did not compare identical.
Using == to compare objects if you don't mean to check identity is to be considered suspect and should be avoided. The equals methods of both types are overridden to compare the boxed values (as opposed to object identity) which is why they return true in both cases (and should be used).
Initialize the Integers the following way then you will get the difference as #5gon12eder said
The Integer s i and j are constructed (via auto boxing) from integer literals from the range –128 to 127 which are guaranteed to be pooled by the JVM so the same object (see flyweight pattern ) is used for them. Hence, they compare equal by object references.
try this code to initialize your integers
Integer i = new Integer(10);
Integer j = new Integer(10);
This question already has answers here:
Integer wrapper objects share the same instances only within the value 127? [duplicate]
(5 answers)
Closed 8 years ago.
I was writing some test code and found one strange thing, and still confused how this is happening?
Integer i1 = 220;
Integer i2 = 220;
System.out.println(i1 == i2);
prints false as expected. But
Integer i1 = 20;
Integer i2 = 20;
System.out.println(i1 == i2);
prints true, but both are different references referring to different objects (I assume that).
How come second snippet prints true?
The == operator only works for Integer values between -128 and 127. That is why it doesn't work for 220 but does for 20. In general it is best to always use .equals() when comparing Integers and you should never rely on the == operator.
More information can be found here: https://www.owasp.org/index.php/Java_gotchas#Immutable_Objects_.2F_Wrapper_Class_Caching
This question already has answers here:
Using == operator in Java to compare wrapper objects
(8 answers)
Integer wrapper class and == operator - where is behavior specified? [duplicate]
(2 answers)
Weird Integer boxing in Java
(12 answers)
Closed 9 years ago.
public class IntegerVsInt {
public static void main(String args[])
{
int a = 1;
int b = 1;
int c = a + b;
System.out.println(c);
System.out.println(a == b);
Integer x = 1;
Integer y = 1;
Integer z = x + y;
System.out.println(z);
System.out.println(x == y);
}
}
In the above code I am comparing two int's and two objects of type integer.
When you compare two int's
a == b
I would expect their values to be compared.
However when you compare two Integer's
x == y
I would expect the address of the two object to be compared and then return a false.
I get true in both the cases? Why is this behavior?
The == is testing whether the Integers are the same object. In java, certain small values are required to be cached, as well as others may optionally be cached, which is why the == Object reference evaluates to true.
The snippet from the JLS Spec 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.
x == y
is true for values between -128 and 127 due to integer caching.
Try
Integer x = 130;
Integer y = 140;
Now compare and see the magic.
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.
Reason:
The behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might.