为什么java.util.Collection上有迭代器（）方法

为什么接口java.util.Collection上定义了迭代器（）方法，而它已经扩展了定义了此方法的java.util.Iterable

我正在考虑某种向后兼容性，或者是在集合级别编写一些关于该方法的JavaDoc的机会

---

还有其他想法吗？

向后兼容。Iterable直到1.5版本才引入for（Object o:Iterable）构造。以前，所有集合都必须提供一种方法来迭代它们。

我怀疑这只是为了避免从文档的角度删除方法。尽管javadoc很好，但是很难注意到/注意到一个方法从一个接口移动到一个超级接口

注：1.5中也介绍了Closeable

---

据我所知，从集合类中删除该方法不会出现二进制兼容性问题。

Iterable是在1.5中引入的。因为它是1.5版本之前的一部分，所以他们可能只是没有删除它。正如另一位撰稿人所指出的，它确实有更好的JavaDoc。

我对此做了更多的研究，发现equals（）和hashcode（）方法也被覆盖

---

显然，唯一的原因可能是添加javadoc-可能这就是迭代器（）也被覆盖的原因。

很好，我支持向后可比性，但不确定是否存在类似的SO问题（我的google fu缺少）处理具有相同方法声明的

Set

vs

Collection

，迭代器（）的存在不仅仅是为了向后兼容；直接拥有迭代器的句柄通常很有用。@Adamski，Dan在问，当Collection扩展Iterable时，为什么该方法同时在Collection和Iterable上声明。你的观点似乎是在解决“为什么会有一个method.iterator（），period？”这个问题，没有人会问。是的，对不起；我意识到了这一点，并把我的答案弄糟了！我还相信foreach循环（对象o:Iterable）是由编译器重写的，以使用迭代器。没有迭代器意味着没有foreach:）这个答案实际上是不正确的。

集合

中的声明对于源代码或二进制代码兼容性都不是必需的。实际上，也没有任何源代码兼容性问题。（

Collection

interface，顺便说一句）。我相信您需要一个元语言工具，比如反射，来在运行时分辨差异。