Java8默认方法会破坏源代码兼容性吗？

Question

通常情况下，Java源代码是向前兼容的。在Java8之前，据我所知，编译的类和源代码都与后来的JDK/JVM版本实现了前向兼容。[更新：这不正确，请参阅下面的注释re'enum'等。]但是，在Java8中添加了缺省方法之后，情况似乎不再是这样了。

例如，我一直使用的库有一个java.util.list的实现，它包括一个列表 sort() 。此方法返回已排序列表内容的副本。这个库作为jar文件依赖项部署，在使用JDK1.8构建的项目中运行良好。

但是，后来我有机会使用JDK1.8重新编译库本身，发现库不再编译了：带有自己的sort()方法的list实现类现在与Java 8Java.util.list.sort()默认方法冲突。Java8sort()默认方法对列表进行排序（返回void)；我的库的sort()方法--因为它返回一个新的排序列表--具有不兼容的签名。

所以我的基本问题是：

• 由于默认方法，JDK 1.8不是引入了Java源代码的前向不兼容性吗？

还有：

• 这是第一次这样的前向不兼容更改吗？
• 在设计和实现默认方法时，是否考虑或讨论了这一点？是否在任何地方记录？
• 相对于所带来的好处，（承认很小的）不便是否被打折扣了？

下面是一些在1.7下编译运行，在1.8下运行--但不在1.8下编译的代码示例：

import java.util.*;

public final class Sort8 {

    public static void main(String[] args) {
        SortableList<String> l = new SortableList<String>(Arrays.asList(args));
        System.out.println("unsorted: "+l);
        SortableList<String> s = l.sort(Collections.reverseOrder());
        System.out.println("sorted  : "+s);
    }

    public static class SortableList<V> extends ArrayList<V> {

        public SortableList() { super(); }
        public SortableList(Collection<? extends V> col) { super(col); }

        public SortableList<V> sort(Comparator<? super V> cmp) {
            SortableList<V> l = new SortableList<V>();
            l.addAll(this);
            Collections.sort(l, cmp);
            return l;
        }

    }

}

下面显示了正在编译（或失败）并正在运行的代码。

> c:\tools\jdk1.7.0_10\bin\javac Sort8.java

> c:\tools\jdk1.7.0_10\bin\java Sort8 this is a test
unsorted: [this, is, a, test]
sorted  : [this, test, is, a]

> c:\tools\jdk1.8.0_05\bin\java Sort8 this is a test
unsorted: [this, is, a, test]
sorted  : [this, test, is, a]

> del Sort8*.class

> c:\tools\jdk1.8.0_05\bin\javac Sort8.java
Sort8.java:46: error: sort(Comparator<? super V>) in SortableList cannot implement sort(Comparator<? super E>) in List
                public SortableList<V> sort(Comparator<? super V> cmp) {
                                       ^
  return type SortableList<V> is not compatible with void
  where V,E are type-variables:
    V extends Object declared in class SortableList
    E extends Object declared in interface List
1 error

Answer 1

JDK1.8不是由于默认方法而引入了Java源代码的前向不兼容性吗？

超类或接口中的任何新方法都可能破坏兼容性。默认方法降低了接口中的更改破坏兼容性的可能性。从缺省方法打开了向接口添加方法的大门的意义上来说，您可以说缺省方法可能会导致某些兼容性中断。

这是第一次这样的向前不相容的变化吗？

这种方案有可能引入源不兼容，因为库接口被修改以插入与现有类中的方法不兼容的新方法。（例如，如果一个类有一个浮点值的xyz（）方法并实现了Collection，而我们向Collection添加了一个int值的xyz（）方法，那么现有的类将不再编译。）

相对于好处，（承认很小的）不便是否被打折扣了？

之前换一个接口肯定会破坏兼容性。现在，它可能会。从“肯定”到“可能”，既可以是正面的，也可以是负面的。一方面，它使向接口添加方法变得可行。另一方面，它为您看到的不兼容打开了大门，不只是类，接口也是如此。

null

一旦发布，就不可能在不破坏现有实现的情况下向接口添加方法。一个库发布的时间越长，这种限制就越有可能给它的维护者造成悲痛。

在JDK7中向Java语言添加闭包对老化的集合接口造成了额外的压力；闭包最重要的好处之一是它允许开发更强大的库。如果添加一个语言特性，使库更好，而同时又没有扩展核心库以利用该特性，那将是令人失望的。