为什么要用@interface来定义注解呢？
我已经在 Java 中使用注释或作为最终用户使用了一段时间，但最近我决定研究创建自己的注释类型，并且我发现在 Java 中使用 @interface 定义注释的语法非常奇怪。我的问题是为什么Java使用@interface来定义注释而不是像枚举那样引入新的关键字？我缺少 @interface 语法的一些优点吗？
我很想了解注释设计者所经历的设计注意事项，我确信他们一定考虑过引入新关键字来定义注释的想法。
@interface 有太多限制，例如您不能使用扩展，在定义注释成员（例如日期）时不能使用某些特定类型。我发现@interface 中可以输入的内容的限制并不明显，对我来说这感觉就像是黑客攻击。
I have been using annotations in Java or a while as an end user but recently I have decided to look into creating my own annotation types and I find the syntax for defining annotations in Java with @interface to be very strange. My question is why does Java use @interface to define annotations instead of introducing a new keyword like they did for enums? Is there some advantage of the @interface syntax that I am missing?
I am tying to understand the design considerations that the designers of annotations went through I am sure they must have toyed with the idea of introducing a new keyword to define annotations.
@interface has too many restrictions for example you can't use extend, there are specific types you can not use when defining an annotation member such as Date. I find the restrictions on what can go into @interface to be not obvious and it just feels like a hack to me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不知道这种特殊情况的确切考虑因素，但总的来说：
在语言中引入新关键字会破坏恰好使用该特定关键字作为标识符的所有现有源代码的兼容性。
现有的源代码无法使用新的编译器版本进行编译，除非对其进行了更改以避免使用该关键字。这并非不可能克服（如
enum案例所示），但它很尴尬并且迫使很多人做额外的工作。 Java 的设计者通常试图在不破坏源代码兼容性的情况下引入新的语言功能。就您提到的
enum而言，我猜他们认为它是 (a) 其他 C 风格语言中的常见关键字，(b) 通常仅用作现有的本地范围标识符代码，因此很容易重构，并且（c）没有任何明智的替代方案。他们认为收益大于成本。对于注释案例，他们显然另有决定。顺便说一句，您可能有兴趣观看 Josh Bloch 的有效 API 设计演讲，其中涉及很多内容这些考虑因素。
I don't know the exact considerations for this particular case, but in general:
Introducing a new keyword into a language breaks compatibility of all existing source code that happens to use that particular keyword as an identifier.
The existing source code cannot be compiled with the new compiler version until it's been changed to avoid the keyword. This is not impossible to overcome (as the
enumcase demonstrated), but it's awkward and forces a lot of people to do extra work. Java's designers have generally tried to introduce new language features without breaking source code compatibility.In the case of
enum, which you mentioned, I guess they decided that it's (a) a common keyword in other C-style languages, (b) generally used only as a local-scope identifier in existing code and thus easily refactored and (c) without any sane alternatives. They decided that the benefits outweighed the costs. For the annotation case, they apparently decided otherwise.As an aside, you may be interested in watching Josh Bloch's Effective API Design talk which touches on a lot of these considerations.
注解声明通常看起来非常恶心。
他们可能认为，只有少数（专家）会声明和处理注解，大多数程序员只会使用专家设计的注解。因此他们并没有想太多去美化注解声明。
enum应该是大多数程序员在日常工作中使用的，因此语法必须简洁。但现在越来越多的框架（如 Guice/CDI）要求/鼓励应用程序程序员声明自己的注释。许多程序员有足够的勇气来设计和处理自己的注释。注解声明语法混乱的问题变得更加突出。
Annotation declarations are generally very disgusting to look at.
They probably thought that, only few (experts) will declare and process annotations, most programmers will simply use annotations designed by experts. Therefore they didn't think too much to beautify annotation declarations.
enumis supposed to be used by most programmers in their daily job, so the syntax has to be succinct.But now more and more frameworks like Guice/CDI require/encourage app programmers to declare their own annotations. And many programmers feel brave enough to design and process their own annotations. The problem of messy syntax of annotation declarations becomes more prominent.
显然设计者并不想添加关键字。这不是你轻易做的事情，因为它会使现有的正确程序失效。 Cobol-9x 委员会添加了数十个甚至数百个关键字，您应该已经听到了尖叫声。一些公司正在讨论起诉标准机构。
Clearly the designers didn't want to add a keyword. Not something you do lightly, as it invalidates existing correct programs. The Cobol-9x committe added dozens if not hundreds of keywords and you should have heard the screams. Some companies were talking about suing the standards body.