-1
int a = 30;
Integer b = new Integer(30);
if( b1 == b2)
    System.out.println("Hello");
else
    System.out.println("Hi");

Output : Hello

Right. As a will also point to integer Object of b. Also explained here : Comparing Integer objects

But If I execute :

class A2
{
    public static void main(String args[])
    {
        int a = 30;
        Integer b1 = new Integer(30);
        Integer b2 = new Integer(30);
        if(a == b1 && a == b2)
            System.out.print("Hello");
        else
            System.out.print("Hi");
        if( b1 == b2)
            System.out.print("Hello");
        else
            System.out.print("Hi");
    } //End of Method
}// End of class

Output : Hello Hi

Second Output is fine as now, b1 and b2 have separate objects. But now where will "a" point to ?? Please explain the reason of "Hello" output here.

Lothar
  • 5,323
  • 1
  • 11
  • 27
coderAJ
  • 310
  • 5
  • 17
  • [Please see this link](https://stackoverflow.com/questions/29139274/how-equal-operator-works-with-primitive-and-object-type-data) – MehmanBashirov Sep 12 '17 at 10:38
  • You answered your question in the first output. As `a` will also point to integer object of `b`. So, in this case as well it's the same. – Procrastinator Sep 12 '17 at 10:40
  • An `int` doesn't _point to_ anything! While the value of an `int` might be equal to the value wrapped by some `Integer` instance, the `int` certainly doesn't point to that, or any other, `Integer`. – Kevin Anderson Sep 12 '17 at 11:02

2 Answers2

0

Compiler actually changes it to the following: if(a == b1.intValue() ){}

MehmanBashirov
  • 641
  • 1
  • 7
  • 15
0

If you compare a primitve int with an Integer the latter get autoboxed to an int using the method intValue(). If you compare two instances of type Integer using val1 == val2 the reference is compared, which are different here, because you created two different instances of Integer containing the same int-value.

Some notes:

Instead of using the constructor, you can create instances of Integer by using the valueOf(int) method. This method returns cached values if the passed argument is within a particular range (30 is within it), your two instances would have ended up to be the same in your above example when changing to valueOf.

Personally I see autoboxing as a potential source for errors and I actually configured my IDE to regard autoboxing as an error. With above explanation you might already guess, why: Autoboxing is done by using value.intValue(). If the value happens to be null you end up with a NullPointerException. But that's personal taste (and willingness to take risks), so YMMV.

Lothar
  • 5,323
  • 1
  • 11
  • 27
  • As a contrasting point, more recent languages than Java (such as Groovy, and possibly the future Java 10) make no distinction between boxed and unboxed types; int and Integer are synonymous. All required boxing/unboxing is done automatically – even when you use `==`. – Klitos Kyriacou Sep 12 '17 at 10:55
  • @KlitosKyriacou I've read about that as well. What happens in the case I mentioned then? – Lothar Sep 12 '17 at 10:56
  • For example in Groovy `val1 == val2` is equivalent to `val1.equals(val2)` as operators are just syntactic sugar for specific method calls. – Klitos Kyriacou Sep 12 '17 at 11:12
  • @KlitosKyriacou And what happens if `val1` is `null`? In Java you get a `NullPointerException` for the latter statement. – Lothar Sep 12 '17 at 12:13
  • It would simply return false if val2 is not also null. That's because what happens is a little more complicated than how I explained. It depends on the type of object. For null, it's only ever equal to null. If the object is of a class that implements Comparable, it calls compareTo. – Klitos Kyriacou Sep 12 '17 at 13:14