The typical use-case is for simple things like @Override, but clearly you can do a lot more with them. If you push the limits of them, you get things like Project Lombok, though my understanding is that that's a huge abuse of annotations. What exactly can you do? What sort of things can you do at compile-time and run-time with annotations? What can you not do?
-
2looking at Lombok is funny, from the @Data annotation: "A shortcut for @ToString, @EqualsAndHashCode, @Getter on all fields, and @Setter on all non-final fields. You even get a free constructor to initialize your final fields!" if you need a tool to automatically generate getters and setters on all your fields, something is wrong with your code.. – Claudiu Jun 06 '10 at 18:33
-
@Claudiu: Not to mention that "@Setter on all non-final fields" is just plain outright *wrong* thing to do. – Jun 06 '10 at 18:41
-
@doublep, in many cases it *is* the right thing. Not in all cases, but hey, then you don't use it. – gustafc Jun 06 '10 at 18:44
-
2@gustafc: if it's the right thing to do, declare those fields public. – Claudiu Jun 06 '10 at 18:44
-
@Caludiu, sometimes you need it for DTO type objects, where the getters and setters are just so much boilerplate. – Yishai Jun 06 '10 at 18:56
-
@Claudiu: No you don't. Not ever, at least not in Java. It's non-idiomatic and you have to break binary compatibility if you decide to change the implementation. – gustafc Jun 06 '10 at 19:01
-
@swampsjohn: Best Java addition *ever* was when IDEs started supporting the *@NotNull* annotation. I can't understand why everyone is not using this. This should be mandatory. In IntelliJ IDEA, you're warned in real-time (even on partial AST, ie non-compilable *.java* file) about possible violations: *"method xxx may return null but it is annotated as @NotNull"*. Best. Annotation. Ever. – NoozNooz42 Jun 07 '10 at 02:50
-
@Claudiu: http://en.wikipedia.org/wiki/Object-oriented_programming Most notably the *"encapsulation"* part ;) Not that Java makes it that easy to pass clean OO messages around but it's not a reason to willfully break encapsulation ;) – NoozNooz42 Jun 07 '10 at 02:52
5 Answers
We use runtime annotation together with reflection to customize our Domain Model Mapping to the database. Also our form validation is based on Annotations in the code used at runtime.
In addition you can use the Annotation Processor which comes with Java to preprocess your Source files
EDIT: And with lombok, as asked in the Question there was added a new more powerful way of using this Annotation processing than mostly everyone here thought to be possible. Let me describe this for you in a few words: They hook the Java Annotation Processing step in
- The Java-Compiler and
- the Eclipse IDE where the parse tree for your code is generated.
This way eclipse shows you more code that you really wrote, and the javac believes the same. The generator technic uses old style Java Annoation Processing, but you can think of Lombok as the missing glue everyone needed to make it really useful.

- 4,433
- 2
- 26
- 37

- 27,718
- 20
- 89
- 133
Annotations belongs to reflection. Annotations alone don't provide anything, you need to use them either in your code, or use them jointly with things like dynamic proxy or byte-code rewritting, which also belong to the field of reflection.
Reflection is known as something extremely powerful but at the same time that can be dangerous.
I think the underlying question is: "what are the legitimate uses of annotations, or more generally reflection?".
Because there is tension between reflection and safety (breaks type system, access to final fields, etc.), there are then two camps: those who embrace meta-programming and those who embrace safety. What's legitimate is ultimately a matter of taste and opinion.
Related questions:
Based on your comment it seems like you are mostly interest about JSR-269 and hooking in the compilation process. I see two use cases for JSR-269: for custom error/semantics checks (e.g. Override), for DSL/language engineering. Whether it's widely used apart for hacking and experiment, I don't know. Here are nevertheless cool links from a colleague:
That said, I would say that byte-code transformation/compiler hooks still belongs to meta-programming. For instance you can generate getter/setter like in Lombok at compile-time, or use a dynamic proxy that do that at run-time. So to me, this duality means that we're still in the field of reflection.
-
It's a good point, but annotations also have the opposite property - they can introduce type safety into situations that would have none (such as when the alternative is XML configuration). Google Guice is a good example of that type of use of annotations. – Yishai Jun 06 '10 at 18:58
-
1I disagree with your assessment of the underlying question. I would like to know what sorts of things you can do by writing annotation processors, not what the "legitimate uses" are, and it's not really a question about reflection. I'm just wondering how much power you can get by being able to hook into the compilation processor. I'm not asking what good programming practices are. – swampsjohn Jun 06 '10 at 19:02
-
@swampsjohn It seems like you are interested in using annotation at compile-time, not that much about run-time. I've edited my answer. – ewernli Jun 06 '10 at 20:02
I'm pretty sure you can't use annotations to do laundry.
But other than that, here are some of the real limitation of annotations in my experience:
- They are static. This means that you cannot have some dynamic runtime configuration replace them. So if you have database information retrieved from an annotation, that can be very limiting. Frameworks that do that tend to end up needing both configuration mechanisms, annotation and some XML or other dynamic mechanism. Not exactly wonderful.
- Related to number 1, they are difficult to test. Imagine a framework that has to process some annotation. Creating all of the variations to test is a lot of boiler plate.
- They are hard to consume. Both the reflection gotchas and just general difficulties make it so that they are appropriate for a framework to asks its users to write an annotation, but you would never want to have a user of the framework have to analyze the annotations on a parameter to determine anything.

- 90,445
- 31
- 189
- 263
Annotations are metadata, information about information - in this case your code.
With annotations, you can provide hints and clues to the consumer of the annotation, such as the compiler or the code itself at runtime. I have used them carefully on a few occasions, where their presence replaced the need for some other boolean comparison evaluating to true, and the attributes provided further information about what actually needed to be done because the annotation was present.
Regarding what you can't do with annotations .. I'm not sure how to answer that. Use them if they solve a real problem or make your code more elegant, but don't force it.
Pardon me possibly over-simplifying things.

- 10,647
- 2
- 31
- 29
-
Could you please give an example or a link on how to generate code with annotations (as seen in Project Lombok)? – Simon Jun 06 '10 at 18:40
This question is very (too?) broad so I will just give one example that I find interesting. JPA 2.0 relies on annotation processing to generate static metamodel classes for entities (used for type safe queries with the Criteria API).
See also
- Hibernate Static Metamodel Generator Annotation Processor
org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor
(Hibernate's implementation)

- 562,542
- 136
- 1,062
- 1,124