14

What is the difference between the following:

Integer in = (Integer)y;

and

Integer in = new Integer(y);

I want to convert int type to Integer type and vice versa. Here is my code for doing that:

public class CompareToDemo {

  public static void main(String[] args) {
    // Integer x=5;
    int y=25;

    System.out.println(y+" this is  int variable");

    Integer in = (Integer)y;

    //Integer in = new Integer(y);

    if(in instanceof Integer){
      System.out.println(in +" this is Integer variable");
    }
  }
}
Cache Staheli
  • 3,510
  • 7
  • 32
  • 51
sunny ranjan
  • 143
  • 6
  • 6
    For this convertion you should use `Integer.valueOf()`. From the javadoc "If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested value" – Jens Jul 04 '16 at 05:56

3 Answers3

9

Briefly speaking,

  • The line Integer in = (Integer)y; uses an unnecessary cast.
  • The line Integer in = new Integer(y); creates an Integer instance.

Each case in detail

First, let's consider the case with explicit casting.

Integer i = (Integer)10;

The compiler understands that 10 is an int primitive type and the fact that it has to be wrapped by its Integer to make it compiles. It seems javac will make the following:

Integer i = (Integer)Integer.valueOf(10);

But the compiler is smart enough to do unnecessary casting, (Integer) just will be omitted:

Integer i = Integer.valueOf(10);

Next, there is the case with instance creation.

Integer i = new Integer(10);

Here is all simply. A new instance of Integer class will be created anyway. But, as the documentation says, usually, it is not appropriate way:

It is rarely appropriate to use these constructors. The static factories valueOf() are generally a better choice, as it is likely to yield significantly better space and time performance.

Conclusion

In everyday code writing, we usually use autoboxing and unboxing. They are automatic conversions between the primitive types and their corresponding object wrapper classes (has been introduced in Java 5). So you needn't think much about Xxx.valueOf(xxx) and .xxxValue() methods. It is so convenient, isn't it?

Integer i = 10; // autoboxing
int j = i; // unboxing
Andrew Tobilko
  • 48,120
  • 14
  • 91
  • 142
  • 2
    "You needn't think about." - Only point of objection. I do not argue that the VM handles the "dirty" work for you - **but** you still need to be aware of what is going on. Just the other day there was a question where a guy messed up thread synchronization because of the Integer pooling mechanism. – Fildor Jul 04 '16 at 07:17
  • 2
    @Fildor: using `Integer` instances as synchronization key is a broken design anyway, regardless of whether pooling happens or not. – Holger Jul 04 '16 at 09:28
  • 2
    @Holger I agree. But that was not my point. I just wanted to say "You need not think about" is **simply not true**. _Of course_ you have to know that there is some Boxing/Unboxing going on behind the scenes. Otherwise you _will_ get into trouble sooner or later. The example with that synchronization issue was just one of many thinkable. – Fildor Jul 04 '16 at 09:32
9

If all you want to do is to convert an int primitive to an Integer object, you have four options

   Integer in = (Integer)y;         // 1 explicit cast
   Integer in = y;                  // 2 implicit cast (autoboxing)
   Integer in = new Integer(y);     // 3 explicit constructor
   Integer in = Integer.valueOf(y); // 4 static factory method

The most preferable way here is 2 (autoboxing). The explicit constructor (3) is the less preferable, as it might have some small performance hit.

Also, they are not strictly equivalent. Consider:

public static void main(String[] args) {
    int x = 25;
    Integer a = new Integer(x);
    Integer b = new Integer(x);
    System.out.println(a == b);     // false
    Integer c = Integer.valueOf(x);
    Integer d = Integer.valueOf(x);
    System.out.println(c == d);     // true
    Integer e = (Integer)x;
    Integer f = (Integer)x;
    System.out.println(e == f);     // true
}

This is because small integers are cached (details here).

Community
  • 1
  • 1
leonbloy
  • 73,180
  • 20
  • 142
  • 190
4

For every primitive type in java, there is a corresponding wrapper class. You can convert between these primitive type and corresponding wrapper class. This is called boxing and unboxing. When you write 

Integer in = (Integer)y; //this is unnecessary casting

or

Integer in = new Integer(y); //create a new instance of Integer class

You're mainly converting between primitive type and wrapper class. But Java has a feature called Auto Boxing and Unboxing Where java will do these casting for you. Just write 

int iPrimi = 20;
Integer iWrapper = iPrimi; //Autoboxing 
int iPrimi2 = iWrapper; //Auto unboxing

Autoboxing and Unboxing decrease performance. Primitives seems to be 2-3 times faster then it’s Integer equivalent. So do not use them if you don't need to.

LegionMammal978
  • 680
  • 8
  • 15
Emdadul Sawon
  • 5,730
  • 3
  • 45
  • 48