The value of Integer.valueOf()

Question

Is there any reason to use Integer.valueOf(X) to initialize a final Integer, as below:

public class MyClass
{
  public static final Integer DAY_1 = Integer.valueOf(1); // Why do it this way?
  public static final Integer DAY_2 = 2; // When it can be done this way?
}

I understand this was necessary in older versions of Java before autoboxing was added. Does any reason for this type of code remain? Or is it just a bad habit?

Answer 1

• There's a lot of code written before 1.5 came out. There's no need to update it all without bringing any benefit.
• In some cases it makes it clearer that you are boxing. In the case you gave you can easily see the target type on the same line - but that's not always the case.
• If you want to call a method which has overloads for both Integer and int and you want to call the Integer overload, this is an easy way to do it.

Answer 2

A programmer might choose to write it this way in order to emphasize visually that DAY_1 is an Integer (object), not an int.

I'm not saying I recommend it, but I could imagine someone taking this approach for that reason.

Answer 3

In addition to Jon's reasons, some people simply don't like auto (un)boxing, period. There are many nuances to it that some people choose to categorically avoid by prohibiting its use in general through optional compile errors or warnings (Eclipse can turn them into errors or warnings, e.g.)

If that's the case, there isn't much choice besides using the first, even in cases like this where it's not really gaining much.

Answer 4

As far as the compiler is concerned, there's no difference (although one should use care in the case of overloaded arguments). Under the hood, the form shown for DAY_2 is simply converted to the form used for DAY_1 by the compiler.

For human beings, there might be a difference. I typically avoid auto(un)boxing as an act of defensive programming, because I feel that the practice makes it too easy for me to forget the null case. But really, it's up to you.

Answer 5

Autoboxing can lead to very subtle bugs that may be very difficult to find. Because of this, some IDEs have ability to generate a warning when any kind of boxing/unboxing is used. If you want to silence this warnings option 1 will do it for you.

So, in the end, it all comes down to personal preferences and project's coding standards.

In this particular case, there is no danger for using autoboxing.

Answer 6

Integer.valueOf(1) allows caching of common values; for the values from -128 to 128, it will always return the same object for example, whereas new Integer(1) will always return a new object. I would say it is good practice to use this for all Number derived types (Integer, Long, BigDecimal, etc.), even though this is probably what autoboxing is doing under the covers anyway.

Bart van Heukelom, the difference between list.remove(1) and list.remove(new Integer(1)) is this; list.remove(1) will remove the object at index 1 from the list, list.remove(new Integer(1)) will remove all objects in the list that are equal to the Integer object with a value of one. Remember that Collections cannot store primitives, only objects.

Answer 7

It's a bad habit and there's no reason to do it since the compile will generate the Integer.valueOf() for you.