20

When I look at Java frameworks like Hibernate, JPA, or Spring, I usually have the possibility to make my configuration via an xml-file or put annotations directly in my classes.

I am cosistently asking myself what way should I go.

When I use annotations, I have the class and its configuration together but with an xml I get a bigger picture of my system because I can see all class-configurations.

Annotations also get compiled in some way I guess and it should be quicker than parsing the xml, but on the other hand, if I want to change my configuration I have to recompile it instead of just changing the xml file (which might become even more handy for production environments on customer side).

So, when looking at my points, I tend to go the xml-way. But when looking at forums or tutorials usually annotations are used.

What are your pros and cons?

lostiniceland
  • 3,729
  • 6
  • 38
  • 50

3 Answers3

22

A good rule of thumb: anything you can see yourself wanting to change without a full redeploy (e.g. tweaking performance parameters) should really go in something "soft-configurable" such as an XML file. Anything which is never realistically going to change - or only in the sort of situation where you'll be having to change the code anyway - can reasonably be in an annotation.

Ignore any ideas of performance differences between annotations and XML - unless your configuration is absolutely massive the difference will be insignificant.

Concentrate on flexibility and readability.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Thanks. I havent thought of using both at the same time. – lostiniceland Jul 10 '09 at 11:13
  • 2
    Annotations have the advantage of being attached to the code. So it's less likely that they will get out of sync than a separate file. Be sure whatever options are in a separate file are thoroughly covered with unit tests. That said, Your best bet is to head the advice above. – Chris Nava Jul 10 '09 at 14:05
  • 1
    Values that are different depending on the environment that is deployed to (QA vs. production) or that need to be supplied by the person doing the deployment (e.g. a database password) are also good candidates for an external configuration. – NamshubWriter Jul 10 '09 at 14:54
  • Also, with AOP, annotations act more like lisp-y macros. e.g. you see them in the code, they aren't hidden in an unrelated file. – KitsuneYMG Jul 11 '09 at 01:59
3

If you're writing an API, then a word of warning: Annotations can leak out into your public interface which can be unbelievably infuriating.

I'm currently working with APIs where the API vendor has peppered his implementation with Spring MBean annotations, which suddenly means I have a dependency upon the Spring libraries, despite the possibility I might not need to use Spring at all :(

(Of course, if your API was an extension to Spring itself, this might be a valid assumption.)

butterchicken
  • 13,583
  • 2
  • 33
  • 43
  • Annotations do not cause a runtime dependency. See [this comment](http://stackoverflow.com/questions/2468390/dependency-on-springs-annotations/2473776#2473776) about it. – Abhinav Sarkar Jun 17 '10 at 13:49
1

I think the decision comes down to 'lifecycle', and impedance mismatch between lifecycles.

Lifecycle: Every piece of data, whether its source code, a database row, a compiled class, an object, has a lifecycle associated with it. When does it come into existence and when is it garbage collected?

Suppose I put Hibernate annotations on a Java class. Seems like a reasonable idea, especially if I am creating a new database from scratch and am confident that only this one application will ever connect to it - the lifecycles of my classes, the database schema and the ORM mapping are naturally in sync.

Now suppose I want to use that same class in an API and give it to some third party to consume. The Hibernate annotations leak into my API. This happens because the lifecycle of that class and the database are not the same thing. So we end up using mapping tools to translate between layers of beans in a system.

I try to think about lifecycles and that annotations that can cause lifecycle mismatches should be avoided. Some annotations are relatively harmless in this respect, and some are a hidden danger.

Examples of bad annotations: ORM mapping, database configuration, hard coded config for items that may vary between deployment environments, validations that may vary depending on context.

Examples of harmless annotations: REST endpoint definitions, JSON/XML serialization, validations that always apply.

user2800708
  • 1,890
  • 2
  • 18
  • 31