在Java 1.8.0_25发布后,我遇到了一个有趣的情况...... 我相信我的问题根源主要与接口中新的(对于1.8而言)“默认”实现特性有关。
我正在处理的应用程序目前针对1.7进行了优化,并一直运行良好。但是当用户开始升级到1.8时,我们被迫要支持1.8。
我们已经解决了大部分问题(主要涉及JavaFX包在1.7和1.8之间的更改),但仍有一个棘手的问题留下。
在我早些时候创造了一个从AbstractList<T>扩展的SortedList<T>类,这个类到目前为止一直工作正常,但在1.8的运行时环境下运行时,会出现以下错误:
Duplicate methods named spliterator with the parameters () and () are inherited
from the types Collection<T> and Iterable<T>
在我看来,这似乎是由AbstractList<T>实现的某些接口中的“默认”实现引起的(我的SortedList<T>类没有实现除Serializable之外的任何其他接口)。对于我们来说,实现Serializable又是另一个问题,因为我们需要支持SortedList<T>对象的反序列化,这是无法避免的!
我可以通过在SortedList<T>类中提供spliterator()的重写实现来消除错误。然而,如果这样构建,它就不能在Java 1.7环境上运行。如果我尝试在1.7的运行时环境中使用SortedList<T>,我会得到以下错误:
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<T>中的spliterator()方法,它需要包含java.util.Spliterator,但在1.7中不存在。
理想情况下,如果客户不想更新到Java 1.8,我们希望不要让他们强制更新。
这里是否有迫使我们的手?我们需要强制用户更新到1.8并向任何自行更新到1.8的用户发布新版本吗?
有谁知道如何解决这个问题吗?
在更深层次上,为什么Interface被实现污染了 :-(。这可能是一个巧妙的新功能,但他们确实应该避免做任何导致破坏现有代码的更改,特别是在如列表/集合等基本功能中。
对于这种困境的任何帮助或建议将不胜感激。
谢谢,
马克
Collection<T>
扩展自Iterable<T>
,所以不应该出现“重复方法”错误。这是编译器出现问题的指示。请记住,即使您没有使用 Java 8 源代码或目标级别,在使用 Java 8 类时也需要一个Java 8意识的编译器。 - Holger