interface - 接口(interface)中的 Java 8 : Spliterator, 迭代器、集合和 "default"实现(名为 spliterator 的重复方法)

Question

在 Java 1.8.0_25 发布到荒野之后有一个有趣的情况......我相信我的问题的根源主要与接口(interface)中“默认”实现的新(到 1.8)特性有关。

我正在开发的应用程序目前的目标是 1.7，到目前为止它运行良好。直到用户开始更新到 1.8。现在我们的用户已经开始更新到 1.8，我们的手在某种程度上被迫转向 1.8 支持。

我们已经修复了大部分问题(主要与 1.7 和 1.8 之间对 JavaFX 包的更改有关)，但还有一个令人烦恼的问题。

根据我的智慧，或者缺乏智慧，我不久前决定创建一个从 AbstractList 扩展的 SortedList 。到目前为止，这个类运行良好，但是在 1.8 运行时运行时，我得到:

Duplicate methods named spliterator with the parameters () and () are inherited 
from the types Collection<T> and Iterable<T>

在我看来，这似乎是由 AbstractList 实现的某些接口(interface)中的“默认”实现引起的(我的 SortedList 类没有实现除 Serializable 之外的任何其他接口(interface))。实现 Serializable 对我们来说是另一个问题，因为我们需要支持 SortedList 对象的反序列化，没有办法解决这个问题!)。

我可以通过在我的 SortedList 类中提供 spliterator() 的覆盖实现来消除错误。但是，如果构建了它，它就不再在 Java 1.7 环境中运行。如果我尝试将 SortedList 与 1.7 运行时一起使用，我会得到:

Problem:
Error: Unresolved compilation problems:
The import java.util.Spliterator cannot be resolved
Spliterator cannot be resolved to a type

com.xxxx.xxxx.util.SortedList.<init>(SortedList.java:13) 

这个错误非常明显，因为我们现在覆盖了 SortedList 中的 spliterator() 方法，它需要包含 java.util.Spliterator，但在 1.7 中不存在。

理想情况下，如果客户不愿意，我们不希望他们更新到 Java 1.8。

我们的手是被迫在这里吗？ 我们是否需要强制用户更新到 1.8 并且还向任何自己更新到 1.8 的用户推出新版本？

有谁知道解决这个问题的方法？

从更哲学的角度来说，为什么接口(interface)被实现破坏了:-(。可能是一个漂亮的新功能，但他们真的应该避免做任何会导致对现有代码进行破坏性更改的事情，特别是在像列表这样基本的东西中/收藏等

任何有关此困境的帮助或建议将不胜感激。

干杯，

标记

Answer 1

默认方法的重点是避免您描述的情况。下面的代码在 Java 7 和 8 中按预期编译和运行:

public class SortedList<T> extends AbstractList<T> implements Serializable {
  @Override public T get(int index) { return null; }
  @Override public int size() { return 0; }

  public static void main(String[] args) {
    SortedList<String> s = new SortedList<> ();
    System.out.println(s.size());
  }
}