为什么 Java 可变参数不支持集合？

发布于 2024-11-27 02:23:54 字数 346 浏览 2 评论 0原文

在我的 Java 代码中，我经常使用非常方便的 method(Class... args) varargs。据我所知，它们允许您传递任意数量的 Class 对象或 Class[] 数组。由于我也经常使用 Java 集合类，因此我对两者之间缺乏兼容性感到沮丧。结果，我最终做了collection.toArray()，但这存在一些类型安全问题。

现在的问题是：为什么 Java 不允许 Iterable实例作为 vararg 参数，只要泛型类型符合 T... 类型可变参数？不是每个人都一直使用列表、集合等吗？是否有一种简单、类型安全的方法来提供从集合到可变参数的转换？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

旧瑾黎汐 2024-12-04 02:23:54

原因很简单：变量 arity 参数只是一个老式数组参数，带有一些附加元数据，告诉编译器提供一些语法糖（即，它允许隐式数组创建）。

因此，从 JVM 的角度来看，Object... 与 Object[] 几乎相同。允许集合也需要对 JVM 进行更具侵入性的更改（迄今为止，JVM 还没有明确支持集合）。

请注意，如果您想支持这两种方式，那么使用基于集合的方法可能是更好的方法：

public void frobnicate(Object... args) {
  frobnicate(Arrays.asList(args));
}

public void frobnicate(Iterable<Object> args) {
  // do stuff
}

这样做的原因是使用 Arrays.asList() 通常比 Collection.toArray() 更便宜的操作（因为它创建了一个简单的包装器）。

The reason is simple: a variable arity parameter is simply an old-school array paramater with some additional metadata that tells the compiler to provide some syntactic sugar (namely, it allows implicit array creation).

So from the perspective of the JVM Object... is pretty much the same as Object[]. Allowing collections as well would require a more invasive change to the JVM (which has no explicit support for collections to date).

Note that if you want to support both ways, then making the collection-based method is probably the better approach:

public void frobnicate(Object... args) {
  frobnicate(Arrays.asList(args));
}

public void frobnicate(Iterable<Object> args) {
  // do stuff
}

The reason for this is that using Arrays.asList() is usually a cheaper operation than Collection.toArray() (because it creates a simple wrapper).

回复收藏 0 原文

~没有更多了~