Originally posted by Paul Sturrock: Annotations are a way of marking code, not to influence how it behaves, but to influence how tools that read the file treat it.
I don't quite agree with this. The line between the code that contains annotations and the code that processes them can be very fine. After all, any class is capable of reading and processing its own annotations at runtime. That may not be what Sun envisaged annotations being used for, of course, nor good development practice, but it's possible.
Here's an example of a class that reads its own annotations at runtime. Note the RetentionPolicy.RUNTIME setting. [ June 14, 2007: Message edited by: Ulf Dittmer ]
What it boils down to is that annotations are class metadata. As such they can be used for whatever purpose someone can think of. Of course they provide more value if they are standardized, so that annotation-processing code knows what to do if they are encountered.
But there's nothing in them that would prevent someone from inventing new ones for use solely in his own code (or solely for use within a single company).
Note that above I used the deliberately vague term "annotation-processing code". This could be tools like apt -which is used for JAX-WS web services-, or javac (think @Override), or 3rd-party libraries like FindBugs (see here).
Or a class could process its own annotations, like in the example I linked to above. That class doesn't do anything interesting with those annotations - it's just meant to demonstrate that it's possible.
Another interesting example is the web app framework Stripes, which uses annotations for configuration purposes at runtime. It thus needs no configuration files, like Struts does. [ July 07, 2007: Message edited by: Ulf Dittmer ]