views:

172

answers:

6

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?

A: 

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

ColinD
-1 This API was added with Java 5, for a good reason: performance (especially with autoboxing).
Aaron Digulla
Sorry for the downvote, I misunderstood the question.
Aaron Digulla
+4  A: 

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.

Drew Wills
+8  A: 
  • 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.
Jon Skeet
+4  A: 

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.

Mark Peters
+1 count me among them - I think that there are few good reasons for implicit syntax in software development, it causes misunderstandings, ambiguity and potential maintenance troubles in the future.
mikera
@mikera: Ditto. The code base I am working on contains numerous statements like "Double foo=Double.parseDouble(s); double bar=foo;", i.e. they convert a string to a double (primitive), then autobox it into a Double (object), then auto-unbox it into a double (primitive). I'm guessing the writer thought that parseDouble return an object rather than a primitive. Without autoboxing the compiler would have immediately alerted him to his mistake.
Jay
+1  A: 

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.

Robert J. Walker
+1  A: 

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.

Alexander Pogrebnyak