Integer.valueOf() 的值
是否有任何理由使用 Integer.valueOf(X) 来初始化最终的 Integer，如下所示：
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?
}
我知道在添加自动装箱之前，这在旧版本的 Java 中是必要的。这种类型的代码还有什么理由保留吗？或者这只是一个坏习惯？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Integer和int重载的方法，并且您想要调用Integer重载，这是一种简单的方法去做它。Integerandintand you want to call theIntegeroverload, this is an easy way to do it.程序员可能会选择这样编写，以便在视觉上强调 DAY_1 是一个 Integer（对象），而不是 int。
我并不是说我推荐它，但我可以想象有人会因为这个原因而采取这种方法。
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.
除了乔恩的原因之外，有些人根本不喜欢自动（取消）装箱，就这样。它有许多细微差别，有些人选择通过可选的编译错误或警告来禁止一般使用它来绝对避免它（Eclipse 可以将它们变成错误或警告，例如）
如果是这种情况，除了使用之外没有太多选择第一个，即使在这样的情况下，它并没有真正获得太多收益。
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.
就编译器而言，没有区别（尽管在重载参数的情况下应该小心）。在底层，编译器将 DAY_2 显示的形式简单地转换为 DAY_1 使用的形式。
对于人类来说，可能存在差异。我通常会避免自动（取消）装箱作为一种防御性编程行为，因为我觉得这种做法让我很容易忘记空情况。但实际上，这取决于你。
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.
自动装箱可能会导致非常难以发现的微妙错误。
因此，某些 IDE 能够在使用任何类型的装箱/拆箱时生成警告。如果您想消除此警告，请选择选项 1。
因此，最终，这一切都取决于个人喜好和项目的编码标准。
在这种特殊情况下，使用自动装箱没有危险。
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.
Integer.valueOf(1) 允许缓存公共值；例如，对于从 -128 到 128 的值，它将始终返回相同的对象，而 new Integer(1) 将始终返回一个新对象。我想说，将其用于所有 Number 派生类型（Integer、Long、BigDecimal 等）是一种很好的做法，尽管这可能是自动装箱在幕后所做的事情。
Bart van Heukelom，list.remove(1) 和 list.remove(new Integer(1)) 之间的区别是这样的； list.remove(1)将从列表中删除索引为1的对象，list.remove(new Integer(1))将删除列表中等于值为1的Integer对象的所有对象。请记住，集合不能存储基元，只能存储对象。
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.
这是一个坏习惯，而且没有理由这样做，因为编译将为您生成
Integer.valueOf()。It's a bad habit and there's no reason to do it since the compile will generate the
Integer.valueOf()for you.