java接口中方法final,为什么在Java 8接口方法中不允许“final”？

这个问题在某种程度上与Java 8接口方法中不允许“同步”的原因有什么关系？

了解默认方法的关键是，主要的devise目标是界面的演变 ，而不是“把界面变成(平庸)的特质”。 虽然这两者之间有一些重叠，我们试图容纳后者，而不妨碍前者，从这个angular度来看，这些问题是最好的理解。 (还要注意，由于接口方法可以被多次inheritance，所以类方法将与接口方法有所不同，不pipe是什么意图。)

默认方法的基本思想是：它是一个默认实现的接口方法，派生类可以提供更具体的实现。 而且由于devise中心是接口的演进，因此devise中的一个关键devise目标就是能够以源兼容和二进制兼容的方式将默认方法添加到接口中。

对于“为什么不是最终的默认方法”的太简单的回答是，那么身体不会简单地作为默认的实现，它将是唯一的实现。 虽然这个问题有点太简单了，但是它给了我们一个线索，即问题已经在一个可疑的方向上了。

最终界面方法可能存在问题的另一个原因是它们给实现者带来了不可能的问题。 例如，假设你有：

interface A { default void foo() { ... } } interface B { } class C implements A, B { }

这里一切都很好， C从Ainheritancefoo()。现在假设B被更改为有一个foo方法，默认值为：

interface B { default void foo() { ... } }

现在，当我们去重新编译C时，编译器会告诉我们它不知道foo()要inheritance什么行为，所以C必须覆盖它(并且可以select委托给A.super.foo() if它想要保持相同的行为。)但是，如果B已经做出默认的最终决定，而A不在C的作者的控制之下呢？ 现在C不可挽回地被打破; 如果不重写foo() ，它就不能编译，但如果它在B是最终的，则它不能覆盖foo() 。

这只是一个例子，但重要的是，最终的方法实际上是一个工具，在单一inheritance类(通常将状态耦合到行为)的世界中变得更有意义，而不是仅仅贡献行为并且可以被多重inheritance的接口。 这很难说“哪些其他接口可能混入最终的实现者”，并且允许接口方法是最终的可能会导致这些问题(并且他们不会炸毁写这个接口的人，而是在试图实现它的穷人。)

阻止他们的另一个原因是他们不代表你的想法。 仅当类(或其超类)不提供方法的声明(具体或抽象)时才考虑默认实现。 如果默认方法是final的，但超类已经实现了这个方法，那么默认方法将被忽略，这可能不是默认作者在声明最终的时候期望的。 (这种inheritance行为是默认方法devise中心的一个反映 – 接口的演变，应该可以向现有的已经有实现的接口添加一个默认的方法(或者默认的实现)，而不需要改变实现接口的现有类的行为，保证已经在缺省方法之前工作的类在缺省方法的情况下以相同的方式工作。