I do not know the exact considerations for this particular case, but in general:
Introducing a new keyword into the language violates the compatibility of all existing source code that is used to use that particular keyword as an identifier.
Existing source code cannot be compiled with the new version of the compiler until it is modified to avoid the keyword. This cannot be overcome (as the example of enum demonstrated), but it is inconvenient and forces many people to do extra work. Java developers usually tried to introduce new language features without compromising source compatibility.
In the case of the enum you mentioned, I think they decided that it (a) is a common keyword in other C-style languages, (b) is usually used only as an identifier for a local area in existing code, and thus it is easy to refactor and (c) without any reasonable alternatives. They decided that the benefits outweighed the costs. For the annotation case, they apparently decided differently.
As an aside, you might be interested in viewing the Josh Bloch Effective API Design , which addresses many of these considerations.
Barend
source share