简体繁体 English

为什么不为 Generics 自动装箱 Java 原始类型？

[英]Why not auto-box Java primitive types for Generics?

原文 2011-08-12 06:49:39 7 6 java/ generics/ autoboxing

Java does not allow primitive types to be used in generic data structures. Java 不允许在通用数据结构中使用原始类型。 Eg ArrayList<int> is not allowed.例如，不允许使用 ArrayList<int>。 The reason is, primitive types can not be directly converted to Object.原因是，原始类型不能直接转换为 Object。 However Java 1.5 does support auto-boxing, and wrapper classes work in generic data structures.然而 Java 1.5 确实支持自动装箱，并且包装类在通用数据结构中工作。 So why couldn't the compiler auto-box it to ArrayList<Integer>?那么为什么编译器不能将它自动装箱到 ArrayList<Integer> 呢？ Are there any other reasons for why this can not work?还有其他原因导致这不起作用吗？

6 个解决方案

So as far as I understand it, your proposed ArrayList<int> would be identical to ArrayList<Integer> .据我了解，您提出的ArrayList<int>将与ArrayList<Integer>相同。 Is that right?那正确吗？ (In other words, internally it still stores an Integer; and every time you put something in or get it out, it would automatically box/unbox it, but autoboxing/autounboxing already does that for ArrayList<Integer> .) （换句话说，它在内部仍然存储一个 Integer；每次你放入或取出东西时，它都会自动装箱/拆箱，但自动装箱/自动拆箱已经为ArrayList<Integer>做到了。）

If it is the same, then I don't understand what the utility of having a duplicate syntax <int> is when it means the same thing as <Integer> .如果它是相同的，那么我不明白重复语法<int>的用途是什么，因为它与<Integer>的含义相同。 (In fact it will introduce additional problems, because for example int[] is not the same runtime type as Integer[] , so if you have T[] , and T is int , what would it mean?) （实际上它会引入额外的问题，因为例如int[]与Integer[]的运行时类型不同，所以如果你有T[] ，而T是int ，这意味着什么？）

The generic type information is erased at run time.泛型类型信息在运行时被擦除。 Check this link .检查此链接。 Generics have more to do with compile time checking than run time checking. Generics 与编译时检查有关，而不是运行时检查。 The autoboxing and unboxing are the run time operations.自动装箱和拆箱是运行时操作。 See the link .请参阅链接。 This is the reason that autoboxing should not work with Generics.这就是自动装箱不适用于 Generics 的原因。

The problem will be in performance.问题将出在性能上。 For every get() / set() method, in the list, the JVM will have to unbox/box the respective value for the mentioned method respectively.对于每个get() / set()方法，在列表中，JVM 必须分别为上述方法拆箱/装箱相应的值。 Remember, autoboxing take primitive types and wraps them into an Object and vice-versa, as stated on Autoboxing :请记住，自动装箱采用原始类型并将它们包装到Object中，反之亦然，如Autoboxing所述：

Finally, there are performance costs associated with boxing and unboxing, even if it is done automatically.最后，与装箱和拆箱相关的性能成本，即使它是自动完成的。

I think they wanted a List to do simple operation and alleviating performance all together.我认为他们想要一个 List 来做简单的操作和减轻性能。

I don't think there's any technical reason it couldn't be done like you say, but there are always interface considerations: eg, if you automatically converted objects of type ArrayList<int> to be ArrayList<Integer> , you lose some explicitness in terms of the interface specifications: it is less obvious that ArrayList in fact store objects, not primitives.我不认为有任何技术原因不能像你说的那样做，但总是有接口考虑：例如，如果你自动将ArrayList<int>类型的对象转换为ArrayList<Integer> ，你会失去一些明确性在接口规范方面：ArrayList 实际上存储对象而不是原语不太明显。

My understanding is that autoboxing is more for compatibility and flexibility in parameter types than for the ease of being able to say "int" instead of "Integer."我的理解是，自动装箱更多地是为了参数类型的兼容性和灵活性，而不是为了方便说“int”而不是“Integer”。 Java's not exactly known for it's obsession with conciseness... Java 并不完全以其对简洁的痴迷而闻名......

A small PS: I don't think it would technically be correct to say "autobox ArrayLint<int> to ArrayList<Integer> ," because you aren't actually wrapping anything in an object "box" -- you're just actually converting a typename ArrayList<int> to "actual" type ArrayList<Integer>一个小 PS：我认为说“autobox ArrayLint<int> to ArrayList<Integer> ”在技术上是不正确的，因为您实际上并没有将任何东西包装在 object“盒子”中——实际上你只是将类型名ArrayList<int>转换为“实际”类型ArrayList<Integer>

I'm glad it is impossible, because int use much less memory than Integer and is much faster too.我很高兴这是不可能的，因为 int 使用的 memory 比 Integer 少得多，而且速度也快得多。 Therefore it forces me to think whether it is acceptable to use Collection<Integer> or not (lot of times in business application it's ok, but in other apps it is not).因此，它迫使我思考使用Collection<Integer>是否可以接受（在业务应用程序中很多时候都可以，但在其他应用程序中则不行）。 I would be much happier if Collection<int> was possible and efficient, but it is not.如果Collection<int>可行且高效，我会更高兴，但事实并非如此。

I don't think this is any sort of problem - do you have any concrete case where is this limiting you somehow?我认为这不是任何问题——你有什么具体的例子吗？这会以某种方式限制你吗？ And btw there is difference between int and Integer while the object can be null and primitive type can't.顺便说一句，int 和 Integer 之间存在差异，而 object 可以是 null 而原始类型不能。