使用这个新的接口，用户可以更新他的代码，采用默认方法来代替原来的适配器类。通过使用接口代替适配器类的最好的结果是，该类可以继承（extend）其它的类，而不是特定的适配器。现在我们进行实践，移植MyInput类使其使用默认方法。因为我们现在能继承其它类了，所以我们继承一个第三方的基础类。我们这里不需要关心这个基础类的作用，我们可以假设这个对我们的功能是有意义的。
class MyInput extends ThirdPartyBaseClass implements SimpleInput { @Override public void foo() { // do something ... } @Override public void bar() { SimpleInput.super.bar(); // do something additionally ... } } |
为了实现原始类相似的功能，我们使用Java 8的新的语法来调用指定接口的默认方法。同时，将我们方法中的一些逻辑移到基础类中去。此时，你可能拍着我的肩膀说，这是一次非常好的重构！
我们相当成功的使用了该库。但是，维护人员需要增加另一个接口来提供更多的功能。该接口被 ComplexInput 接口所代替，这个接口继承自 SimpleInput 接口，并增加了新的方法。因为默认方法通常来说是可以很安全的添加的，因此，维护人员覆盖了 SimpleInput 的默认方法，提供了一个更好的默认方法。毕竟，这对于采用适配器类的方式来说是很平常的事情。
interface ComplexInput extends SimpleInput {
void qux();
@Override
default void bar() {
SimpleInput.super.bar();
// so complex, we need to do more ...
}
}
新的特性带来了非常好的效果以至于维护 ThirdPartyBaseClass 的人也决定依赖该库。为了完成这项工作，它在 ThirdPartyLibrary 中实现了 ComplexInput 接口。
但是这对 MyInput 类来说意味着什么呢？为了隐式的实现 ComplexInput 接口，可继承 ThirdPartyBaseClass 类，但是调用 SimpleInput 的默认方法突然变成非法的了。结果，用户的代码不能通过编译。现在这种调用是被禁止的，因为Java认为这种在非直接子类中调用父类的父类的方法是非法的。你只能在 ComplexInput 中去调用该默认方法，但是，这要求你显示的在MyInput中实现该接口。对于库的用户来说，这种改变不是所预期的！
更奇怪的是，Java运行时却不做这种限制。JVM的校验器是允许一个编译好的类去调用 SimpleInput::foo 方法的，即使该类是通过继承更新后的 ThirdPartyBaseClass，从而隐式的实现了ComplexClass。这种限制只存在于编译器中。
我们从这里能学到什么东西呢？简单的说，确保不要在一个接口中覆盖另一个接口的默认方法，既不要用默认方法覆盖，也不要用抽象方法覆盖。总的来说，请谨慎使用默认方法。即使它使得Java的集合接口API轻易的发生了革命性的变化，但本质上讲，这种继承层级之间的方法调用，增加系统的复杂性。而在Java 7之前，你只需要沿着线性的类层级去查找真正调用的代码。只有当你觉得非常有必要的时候才去增加这种复杂性。
