在技术层面，哪些障碍阻碍了注解拥有具有实际逻辑的默认方法？

Question

Java 中的注释具有函数（在某些方面其行为类似于属性或字段），并且可能具有默认值。 例如：

public @interface Foo {
  int value() default 1;
}

但是，注释不能具有带有实际主体的方法，即使标记为

default

。

public @interface Foo {
  int value() default 1;

  default int add(int addend) { // NOT ALLOWED
    return value() + addend;
  }
}

Java 语言规范在第 9.6.1 节中指定禁止这样做：

根据上面的语法，注解接口声明中的方法声明不能有形式参数、类型参数或 throws 子句；并且不能是私有的、默认的或静态的。因此，注解接口不能具有与普通接口相同的多种方法。

存在哪些

技术原因导致难以或无法支持（如果有）？ 我并不是在问为什么 Java 设计者可能决定他们不想想要支持这一点——我完全知道这对于 StackOverflow 来说不是一个好问题——但前提是存在可能阻止 JDK 的特定已知问题开发人员不要添加这样的功能。

Answer 1

正如评论中所述，Java 中的注释不允许带有主体的方法有很多非技术原因。我相信，在技术层面上，该语言的功能几乎没有什么限制，但技术限制不仅仅定义了功能，还涵盖了编程语言的整体结构及其执行方式。

在我看来，以下是涉及该主题的 Java 语言技术方面的一些原因：

• 注释是轻量级的元数据描述符。如果允许它们具有方法体，它们将开始与已经处理行为相关逻辑的接口重叠。这会模糊这两个结构之间的区别，并降低它们各自在语言中角色的清晰度。在技术层面上，证明两者存在的合理性变得越来越困难。

• JVM 已经具有管理注释和接口的机制。如果允许注释具有方法体，则 JVM 需要在字节码结构、方法分派和执行方面将它们与接口类似地对待。这会使 JVM 内部对注释的处理变得复杂，而目前注释是非常轻量级的。相比之下，JVM 对接口的处理涉及更多工作，例如方法解析和运行时方法调用，现在注释也需要这些工作。

总而言之，虽然注释是元数据而不是行为最初看起来可能是一种设计选择，但这种选择会导致语言和 JVM 级别的技术约束和限制。克服这些限制需要改变注释的实现、编译和执行方式，这就是为什么这种区别不仅是偏好问题，而且是现有 Java 架构中的技术可行性问题。

我相信“让事情保持简单和可扩展”是避免用语言实现此类功能的一个很好的技术原因。