我一直在使用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