有没有实现 Iterable 而不实现 Collection 的 Java 标准类？

Question

我有一个难题让我思考是否有任何标准的 java 类实现了Iterable<T> 而没有实现Collection<T>。我正在实现一个接口，该接口需要我定义一个接受Iterable<T> 的方法，但我用来支持此方法的对象需要Collection<T>。

这让我做了一些非常笨拙的代码，在编译时会给出一些未经检查的警告。

public ImmutableMap<Integer, Optional<Site>> loadAll(
        Iterable<? extends Integer> keys
) throws Exception {
    Collection<Integer> _keys;
    if (keys instanceof Collection) {
        _keys = (Collection<Integer>) keys;
    } else {
        _keys = Lists.newArrayList(keys);
    }

    final List<Site> sitesById = siteDBDao.getSitesById(_keys);
    // snip: convert the list to a map

将生成的集合更改为使用更通用的 Collection<? extends Integer> 类型并不能消除该行的未经检查的警告。此外，我无法将方法签名更改为接受Collection 而不是Iterable，因为这样它就不再覆盖超级方法并且在需要时不会被调用。

doesn't seem to be a way around 这个转换或复制问题：这里和其他地方已经提出了其他问题，它似乎深深植根于 Java 的泛型和类型擦除系统。但我要问的是，是否有任何类可以实现Iterable<T>，但也不能实现Collection<T>？我查看了Iterable JavaDoc，当然我希望传递给我的界面的所有内容实际上都是一个集合。我想改用一个狂野的、预先编写的类，因为这似乎更有可能实际作为参数传递，并使单元测试更有价值。

由于我正在编写一些单元测试，我确定我编写的强制转换或复制位适用于我在项目中使用它的类型。但我想为是一个可迭代但不是一个集合的一些输入编写一个单元测试，到目前为止我所能想到的正在自己实现一个虚拟测试类实现。

---

出于好奇，我正在实现的方法是 Guava 的 CacheLoader<K, V>.loadAll(Iterable<? extends K> keys)，支持方法是 JDBI 实例化的数据访问对象，它需要一个集合用作 @BindIn 接口的参数类型。我认为我认为这与问题相切是正确的，但以防万一有人想尝试横向思考我的问题。我知道我可以只分叉 JDBI 项目并重写 @BindIn 注释以接受可迭代...

Answer 1

在阅读了出色的答案并提供了文档后，我又浏览了一些课程，发现无论是在测试代码的直接性还是直接的问题标题方面，似乎都是赢家。 Java 的主要 ArrayList 实现包含这个 gem：

public Iterator<E> iterator() {
    return new Itr();
}

其中Itr 是一个私有内部类，具有Iterator<E> 的高度优化定制实现。不幸的是，Iterator 本身并没有实现Iterable，所以如果我想把它硬塞到我的辅助方法中来测试不进行强制转换的代码路径，我必须将它包装在我自己的垃圾类中实现Iterable（而不是Collection）并返回Itr。这是一种方便的方法，可以轻松地将集合转换为 Iterable，而无需自己编写迭代代码。

最后一点，我的最终代码版本甚至没有自己进行转换，因为 Guava 的 Lists.newArrayList 与我在问题中的运行时类型检测中所做的几乎完全相同。

@GwtCompatible(serializable = true)
public static <E> ArrayList<E> More ...newArrayList(Iterable<? extends E> elements) {
  checkNotNull(elements); // for GWT
  // Let ArrayList's sizing logic work, if possible
  if (elements instanceof Collection) {
    @SuppressWarnings("unchecked")
    Collection<? extends E> collection = (Collection<? extends E>) elements;
    return new ArrayList<E>(collection);
  } else {
    return newArrayList(elements.iterator());
  }
}

Answer 2

按标题回答问题：

有没有实现Iterable而不实现Collection的Java标准类？

来自文字：

如果有任何类可以实现Iterable<T>，但又不能实现Collection<T>？

答案：

是的

请参阅以下 javadoc 页面：https://docs.oracle.com/javase/8/docs/api/java/lang/class-use/Iterable.html

任何写有Classes in XXX that implement Iterable 的部分都会列出实现该接口的Java 标准类。其中许多没有实现Collection。

Answer 3

正如@bayou.io 的回答中提到的，Iterable 的一个这样的实现是 Java 7 中引入的用于文件系统遍历的新 Path 类。

如果您碰巧在 Java 8 上，Iterable 已被改造为（即给定一个 default 方法）spliterator()（注意它的实施说明），它可以让您与StreamSupport一起使用：

public static <T> Collection<T> convert(Iterable<T> iterable) {
    // using Collectors.toList() for illustration, 
    // there are other collectors available
    return StreamSupport.stream(iterable.spliterator(), false)
                        .collect(Collectors.toList());
}

这样做的代价是任何已经是Collection 实现的参数都会经历不必要的流收集操作。与原始转换或基于 Guava 的方法相比，您可能只应在对仅 JDK 的标准化方法的需求超过潜在的性能损失时才使用它，这可能没有实际意义，因为您已经在使用 Guava 的 CacheLoader。

要对此进行测试，请考虑以下 sn-p 和示例输出：

// Snippet
System.out.println(convert(Paths.get(System.getProperty("java.io.tmpdir"))));
// Sample output on Windows
[Users, MyUserName, AppData, Local, Temp]

Answer 4

Kludgy，是的，但我认为代码

Collection<Integer> _keys;
if (keys instanceof Collection) {
    _keys = (Collection<Integer>) keys;
} else {
    _keys = Lists.newArrayList(keys);
}

完美无缺。接口 Collection<T> 扩展了 Iterable<T> 并且不允许使用 2 个不同的类型参数实现同一个接口，因此例如，一个类无法实现 Collection<String> 和 Iterable<Integer>。

Integer 是最终课程，因此Iterable<? extends Integer> 和Iterable<Integer> 之间的区别主要是学术性的。

综合来看，最后 2 段证明如果某事物既是 Iterable<? extends Integer> 又是 Collection，那么它一定是 Collection<Integer>。因此，您的代码保证是安全的。编译器无法确定这一点，因此您可以通过编写来抑制警告

@SuppressWarnings("unchecked")

在声明之上。您还应该在注释中添加注释以解释代码安全的原因。

关于是否有任何类实现Iterable 而不是Collection 的问题，正如其他人指出的那样，答案是肯定的。但是我认为您真正要问的是拥有两个接口是否有任何意义。许多其他人都问过这个问题。通常当一个方法有一个Collection 参数时（例如addAll()，它可以并且可能应该是一个Iterable。

编辑

@Andreas 在 cmets 中指出 Iterable 仅在 Java 5 中引入，而 Collection 在 Java 1.2 中引入，并且大多数采用 Collection 的现有方法无法改装为采用 @987654342 @ 出于兼容性原因。

Answer 5

在核心 API 中，只有 Iterable 而不是 Collection 的类型 --

interface java.nio.file.Path

interface java.nio.file.DirectoryStream
interface java.nio.file.SecureDirectoryStream

class java.util.ServiceLoader

class java.sql.SQLException (and subclasses)

可以说这些都是糟糕的设计。

Answer 6

虽然没有类可以立即满足您的需求并且对您的测试代码的读者来说是直观的，但您可以轻松创建自己的易于理解的匿名类：

static Iterable<Integer> range(final int from, final int to) {
    return new Iterable<Integer>() {
        public Iterator<Integer> iterator() {
            return new Iterator<Integer>() {
                int current = from;
                public boolean hasNext() { return current < to; }
                public Integer next() {
                    if (!hasNext()) { throw new NoSuchElementException(); }
                    return current++;
                }
                public void remove() { /*Optional; not implemented.*/ }
            };
        }
    };
}

Demo.

这个实现是匿名的，它没有实现Collection<Integer>。另一方面，它产生一个非空的可枚举整数序列，你可以完全控制它。