为什么@interface用于定义注释？

Question

我一直在Java中使用注释或者作为最终用户使用注释但最近我决定研究创建自己的注释类型，并且我发现使用@interface在Java中定义注释的语法非常奇怪。我的问题是为什么Java使用@interface来定义注释而不是像为枚举那样引入新的关键字？我缺少@interface语法的一些优点吗？

我想要理解注释设计者经历的设计考虑因素我确信他们必须玩弄引入新关键字来定义注释的想法。

@interface有太多限制，例如你不能使用extend，在定义注释成员（如Date）时，你不能使用特定的类型。我发现对@interface的限制并不明显，这对我来说就像是一个黑客。

Answer 1

我不知道这个特定情况的确切考虑因素，但总的来说：

在语言中引入新关键字会破坏碰巧使用该特定关键字作为标识符的所有现有源代码的兼容性。

在更改现有源代码以避免使用关键字之前，不能使用新的编译器版本对其进行编译。这不是不可能克服的（如enum案例所示），但它很尴尬并迫使很多人做额外的工作。 Java的设计者一般都试图在不破坏源代码兼容性的情况下引入新的语言功能。

在您提到的enum的情况下，我猜他们认为它是（a）其他C风格语言中的常用关键字，（b）通常仅用作现有的本地范围标识符代码，因此容易重构和（c）没有任何理智的替代品。他们认为收益超过了成本。对于注释案例，他们显然是另有决定。

顺便说一下，你可能有兴趣看一下触及很多这些考虑因素的Josh Bloch's Effective API Design talk。

Answer 2

注释声明通常非常令人厌恶。

他们可能认为，只有少数（专家）会声明和处理注释，大多数程序员只会使用由专家设计的注释。因此，他们没有太多考虑美化注释声明。大多数程序员在日常工作中应该使用enum，因此语法必须简洁。

但是现在越来越多像Guice / CDI这样的框架需要/鼓励应用程序员声明他们自己的注释。许多程序员都非常勇于设计和处理他们自己的注释。注释声明的混乱语法问题变得更加突出。

Answer 3

显然，设计师不想添加关键字。不是你轻易做的事情，因为它使现有的正确程序无效。 Cobol-9x委员会添加了数十个（如果不是数百个）关键字，你应该听到尖叫声。一些公司正在谈论起诉标准机构。