问题标签 [default-method]

和这个问题一样，我想知道为什么 Java 团队没有在Lock接口中添加一些默认方法，如下所示：

这将允许程序员做

代替

我正在寻找与 C# 扩展方法功能等效的 java。现在我一直在阅读 Java 8 的默认方法，但据我所知，我只能将这些添加到接口中......

...是否有任何语言功能可以让我为不实现接口的最终类​​编写扩展方法？（我宁愿不必包装它......）

在 java 8 我有这样的事情：

有没有办法从 implementsB 调用默认功能接口行为，而不必创建匿名内部类并调用它？

这有一个副作用（调用 implementsA 的方法 2 次），需要调用父级的实现，然后让子级的实现能够调用子级的默认实现，以及一些特殊化（如果需要）。如您所见，调用父级的实现非常容易，但是我看不到避免重写默认实现的方法，除非我向实现子接口的类添加一层间接层，并且无法强制执行.

例如，如果 A 解锁或提供对资源的访问权限，例如数据库，而 B 解锁第二个资源（另一个数据库），我认为没有办法让代码解锁 A，然后 B 通过使用功能接口执行此合同，要求A 和 B 被称为。 一层深你可以做到，但 N 层深看起来是不可能的。

我打算使用 lambdas 来避免进行昂贵的调用，而是对我的库用户强制执行操作的语义顺序。

这个问题与“在 Java 中显式调用默认方法”不太一样，因为这个问题是关于 N 级深度的接口，而不仅仅是调用父接口的默认方法。

我有一个不应从其包外部继承的无状态抽象基类：

现在 Java 8 支持接口中的默认方法，我想将抽象类转换为接口。使用接口，是否也可以防止当前包之外的继承？

我试图在界面中使用默认方法，但是当使用 Eclipse 编译时，我在第 2 行出现错误 - 说删除默认值，但我使用命令提示符编译并运行它运行正常，这可能是什么原因？

在编写加密实用程序类时，我遇到了以下方法的问题：

javax.crypto.spec.SecretKeySpec在上述方法的特定情况下，java7因为SecretKeySpec (javadocs 7)没有实现Destroyable (javadocs 7)

现在，SecretKeySpec (javadocs 8)java8类已经被Destroyable (javadocs 8)和Destroyable#destroy方法现在可以根据这个声明default

默认方法使您能够向库的接口添加新功能，并确保与为这些接口的旧版本编写的代码的二进制兼容性。

然后代码编译没有任何问题，尽管类ScretKeySpec本身没有改变，只有接口SecretKey已经改变。

问题是oracle's jdk8该destroy方法中有以下实现：

这会导致运行时出现异常。

所以二进制兼容性可能没有被破坏，但现有的代码已经被破坏了。上面的测试通过java7但不通过java8

所以我的问题是：

• 通常如何处理可能导致异常的默认方法 - 因为未实现或不受支持 - 或运行时出现意外行为？除了做

  这仅对 java8 有效，并且在将来的版本中可能不正确，因为默认方法可能会获得有意义的实现。

• 将此默认方法保留为空而不是引发异常不是更好吗（IMO 具有误导性，因为除了合法调用销毁之外，没有尝试有效地销毁密钥，UnsupportedOperationException会更合适，你会立即知道发生了什么）

• 我的方法是（类型检查/转换/调用）

  用于判断是否销毁有误？什么是替代方案？

• 这是一种误解，还是他们只是忘记在其中添加有意义的实现ScretKeySpec？

我对 Java 8 中引入的接口中的默认方法实现感到有些困惑。我想知道我们是否应该专门为接口及其实现的方法编写 JUnit 测试。我试图用谷歌搜索它，但我找不到一些指导方针。请指教。

我default在接口中创建了用于实现equals(Object)和hashCode()可预测的方法。我使用反射来迭代类型（类）中的所有字段以提取值并进行比较。该代码依赖于 Apache Commons Lang 及其HashCodeBuilder和EqualsBuilder.

问题是我的测试告诉我，当我第一次调用这些方法时，第一次调用会花费更多时间。计时器使用System.nanoTime(). 以下是日志中的一个示例：

实际代码：

这些方法如何用于实现hashCode和equals：

测试示例：

将这些方法放在接口中的原因是尽可能灵活。我的一些类可能需要继承。

我的测试表明我可以相信 hashcode 和 equals 总是为具有相同内部状态的对象返回相同的值。

我想知道的是我是否遗漏了什么。如果这些方法的行为是可以信任的？（我知道Lombok和AutoValue项目为实现这些方法提供了一些帮助，但我的客户不太热衷于这些库）。

关于为什么第一次执行方法调用总是需要大约 5 倍的时间的任何见解也将非常有帮助。

似乎 Java 8 允许使用如下简单框架实现完全成熟的继承，在接口上使用静态和默认方法。

虽然总是有可能误用和编写愚蠢的代码，但这些新特性使得实现多重继承变得相当容易，即使语言的设计者打算远离它。

这是使用接口作为基类的多重继承的简单实现，还是对语言的滥用？Java 设计者是否允许这样做太过分了？

///////////////////////////////////////// /

或者另一种选择：

这是我在 Java 教程中的简单代码。

我收到一个错误：类型接口方法的非法启动不能有主体。该方法是默认的，默认关键字用于方法签名的开头。你能解释一下有什么问题吗？