我一直在使用Java或一段时间的注释作为最终用户，但最近我决定考虑创建我自己的注释类型，并且我发现用@interface定义Java注释的语法很奇怪。我的问题是为什么Java使用@interface来定义注释，而不是像他们对枚举所做的那样引入新的关键字？我缺少@interface语法的优点吗？为什么@interface用于定义注释？
我很想了解注释设计者所经历的设计考虑因素，我相信他们一定是玩弄了引入新关键字来定义注释的想法。
@interface有太多的限制，例如你不能使用扩展，有一些特定的类型在定义注释成员（如Date）时不能使用。我发现对@interface的限制可能不明显，对我来说就像是一种黑客攻击。
显然，设计师不想添加关键字。不是你轻易做的事情，因为它会使现有的正确程序无效。 Cobol-9x committe增加了几十个关键字，如果不是数百个，你应该听到尖叫声。有些公司正在讨论起诉标准组织。
我不知道这种特殊情况下的具体的考虑，但一般：
引入一个新的关键字进入碰巧使用特定的关键字作为标识符所有现有的源代码语言中断的兼容性。
现有源代码无法使用新的编译器版本进行编译，直到它被更改为避免关键字。这不是不可能克服的（如enum案例所示），但它很尴尬，迫使很多人做额外的工作。 Java的设计人员通常试图在不破坏源代码兼容性的情况下引入新的语言功能。
在你提到的enum的情况下，我猜他们认为它是（a）其他C风格语言中的通用关键字，（b）通常仅用作现有代码中的本地范围标识符，因此容易重构和（c）没有任何理智的选择。他们认为这些好处超过了成本。对于注释案例，他们显然是另有决定。
顺便说一句，您可能有兴趣看Josh Bloch's Effective API Design talk这涉及到很多这些考虑因素。
注解声明通常是非常令人厌恶的。
他们可能认为只有很少的（专家）会声明和处理注释，大多数程序员只会使用由专家设计的注释。因此他们没有多想美化注释声明。 enum应该在大多数程序员的日常工作中使用，所以语法必须简洁。
但是现在越来越多的框架如Guice/CDI需要/鼓励应用程序员声明他们自己的注释。许多程序员都觉得足够勇于设计和处理自己的注释。注释声明的混乱语法问题变得更加突出。
同意JSR 303 Bean验证要求，开发商如果你想要做给验证的核心地位，以建立我认为我在阳光下规范所看到的评论，大多数开发者只需要使用应用的复合验证器注解定义自己的注解，但没有定义注解被短视的。 – ams
能否请您阐述一下你的意思@是不是关键字，编译器将它以特殊的方式，同时规范说，你可以用类似“@接口”与@接口之间的空隙给我定义注释类型感觉就像一个关键字看到我更新的问题，即“为什么不”是不是唯一的应答， – ams
@ams我的道歉，我查了Java的语法，这确实让我已经完全修订我的回答关键字。 – EJP