Java8：为什么禁止为java.lang.Object中的方法定义默认方法

默认方法是Java工具箱中一个不错的新工具。但是，我试图编写一个定义方法default版本的接口toString。Java告诉我这是禁止的，因为在中声明了方法java.lang.Object可能无法default编辑。为什么会这样呢？

我知道有一个“基类总是赢”的规则，因此默认情况下（pun;），default该Object方法的任何实现都会被该方法覆盖Object。但是，我认为没有理由为什么Object规范中的方法不应有例外。尤其是因为toString默认实现可能非常有用。

那么，Java设计者决定不允许default方法覆盖方法的原因是什么Object？

这是语言设计中的另一个问题，在您开始挖掘并且意识到这实际上是一个坏主意之前，这似乎是“显然是个好主意”。

这封邮件涉及到很多主题（以及其他主题。）有多种设计力量融合在一起，使我们进入了当前的设计：

• 保持继承模型简单的愿望；
• 一旦您查看了明显的示例（例如，AbstractList变成一个接口），您就会意识到继承equals / hashCode / toString与单继承和状态紧密相关，并且接口是多重继承和无状态的；
• 它可能为某些令人惊讶的行为打开了大门。

您已经达到了“保持简单”的目标。继承和冲突解决规则的设计非常简单（类胜过接口，派生接口胜过超接口，其他任何冲突都由实现类解决。）当然可以对这些规则进行调整以使其成为异常，但是我想您会发现，当您开始使用该字符串时，增量复杂性并没有您想象的那么小。

当然，有一定程度的好处可以证明更多的复杂性是合理的，但是在这种情况下并不存在。我们在这里讨论的方法是equals，hashCode和toString。这些方法本质上都是关于对象状态的，并且拥有状态而不是接口的类是确定状态对该类意味着什么的最佳位置（尤其是当平等的契约非常牢固时；请参见有效）。 Java带来一些令人惊讶的后果）；接口编写器距离太远了。

AbstractList举个例子很容易；如果我们可以摆脱该问题AbstractList并将其放入List界面中，那将是很可爱的。但是，一旦您超越了这个明显的示例，就找不到很多其他好的示例。从根本上说，AbstractList它是为单一继承而设计的。但是接口必须设计用于多重继承。

此外，假设您正在编写此类：

class Foo implements com.libraryA.Bar, com.libraryB.Moo { 
    // Implementation of Foo, that does NOT override equals
}

该Foo作家着眼于超类型，认为没有实现平等的，并得出结论，得到参考平等，所有他所要做的就是继承平等Object。然后，下周，“有帮助”的Bar库维护者添加了默认equals实现。哎呀！现在，的语义Foo已被另一个维护域中的接口“有用地”破坏了，并为通用方法添加了默认值。

默认值应该是默认值。向没有接口（层次结构中的任何地方）的接口添加默认值不应影响具体实现类的语义。但是如果默认值可以“覆盖” Object方法，那将不是事实。

因此，尽管它看起来像是无害的功能，但实际上却是非常有害的：它增加了很多复杂性，几乎没有增量表达能力，而且对于原本精心设计，无害的更改单独编译的接口来说，破坏太容易了。实现类的预期语义。

禁止在接口中为中的方法定义默认方法java.lang.Object，因为默认方法永远不会“可达”。

可以在实现该接口的类中覆盖默认接口方法，并且即使该方法是在超类中实现的，该方法的类实现也比接口实现的优先级更高。由于所有类都继承自java.lang.Object，因此in中的方法java.lang.Object将优先于接口中的默认方法，并被调用。

Oracle的Brian Goetz在此邮件列表中提供了有关设计决策的更多详细信息。

我看不到Java语言作者的头，所以我们只能猜测。但是我看到很多原因，并且在这个问题上完全同意它们。

引入默认方法的主要原因是能够向接口添加新方法而不会破坏较早实现的向后兼容性。默认方法也可以用于提供“便利”方法，而不必在每个实现类中都定义它们。

这些都不适用于toString和其他Object方法。简而言之，默认方法旨在提供没有其他定义的默认行为。不提供将与其他现有实现“竞争”的实现。

“基层总是赢”的规则也有其扎实的理由。假定类定义了实际的实现，而接口定义了默认的实现，而后者则较弱。

另外，将ANY例外引入通用规则会导致不必要的复杂性并引发其他问题。对象（或多或少）是一个类，为什么它应该具有不同的行为？

总而言之，您提出的解决方案可能会带来比专家更多的弊端。

推理非常简单，这是因为Object是所有Java类的基类。因此，即使我们在某些接口中将Object的方法定义为默认方法，也将是无用的，因为将始终使用Object的方法。这就是为什么要避免混淆的原因，我们不能有覆盖对象类方法的默认方法。

为了给出一个非常古怪的答案，仅禁止从中default为公共方法定义方法java.lang.Object。有11种方法可供考虑，可以通过三种方式进行分类来回答此问题。

1. 六个Object方法不能有default方法，因为他们final和所有不能被覆盖：getClass()，notify()，notifyAll()，wait()，wait(long)，和wait(long, int)。
2. 三种Object方法都没有default通过布赖恩戈茨由于上述原因的方法：equals(Object)，hashCode()，和toString()。

3. 其中两个Object方法可以具有default方法，尽管此类默认值的充其量是可疑的：clone()和finalize()。

   public class Main {
       public static void main(String... args) {
           new FOO().clone();
           new FOO().finalize();
       }
   
       interface ClonerFinalizer {
           default Object clone() {System.out.println("default clone"); return this;}
           default void finalize() {System.out.println("default finalize");}
       }
   
       static class FOO implements ClonerFinalizer {
           @Override
           public Object clone() {
               return ClonerFinalizer.super.clone();
           }
           @Override
           public void finalize() {
               ClonerFinalizer.super.finalize();
           }
       }
   }