ABIS Infor - 2012-06
Java configuration: Annotations vs XML
Abstract
The trend these days in (all of) the Java frameworks is to replace the standard XML configuration file(s) by annotations. Is this indeed for the better, or are there downsides? What are the pros and cons of both approaches? Which of both do you choose, or can they live together in harmony? That is what we will discuss in this article.
The competitors
In the early Java (framework) days, XML was soon adopted as the way to go for configuring enterprise applications. Each framework had their own version: faces-config, struts-config, application context in Spring, hbm files, and so on. Great idea, because XML is portable, standardized and used all over the place.
But the biggest criticism soon was that these XML files could become enormous, or (because of this) split into 1000 little pieces. So other solutions were searched for. With the introduction of Java SE 5, annotations have been introduced. Simple things like @Override, but also a mechanism to build your own. Frameworks also adopted them: Spring 2.5, JSF 2.0, Servlets 3.0, Hibernate 3, EJB 3.0, JUnit 4 (and many others). Annotations like @EJB, @Stateless, @ManagedBean, @Component, @Resource, @Test, @Transactional,... are put on class, field or method level. A lot simpler, shorter and direct it seems. "Zero" configuration (actually configuration by exception) is the goal. Still technology dependent, but standardisation is in progress (@Named, @Inject,...)
To be able to see if annotations are totally the way to go, let's compare the pros and cons of both approaches.
Pros and cons
The biggest disadvantage of XML is indeed its size. Multiple lines are needed for things that you can do in one simple annotation. They are far away from the part in the code where it applies, whereas annotations are just on top of them. So annotations seem a lot more logical and simpler.The use of annotations increases the productivity of the developer a lot.
But on the other hand, this makes that the annotations are spread all over the classes/application again, XML is central to the application. This gives rise to a couple disadvantages of annotations. Your code gets coupled to the used framework(s) and the annotations pollute your POJOs. At a given moment you have more @'s in your class than other stuff. Wasn't reusability one of the main goals in Java? Yes, you are right, annotations will be just ignored if used in another context, but they are still polluting... Considering the Dependency Injection (DI) mechanism, the links between classes are not so clear any more using annotations, whereas in XML you can nicely see the bigger picture.
Other disadvantage of putting annotations in classes is that you will have to recompile a lot more once you want to change some requirements or if you want to have different configurations between development, test and production stages. With XML you can just interchange the files, and the rest of the application stays clean. On the other hand, annotations can be used at compile/deploy/run time, whereas XML is only at deploy time.
So who is the winner?
The piece above seems a bit in favour of XML. But annotations are great as well, certainly now they have become standardized and you can use the same ones in different frameworks (here I am mainly referring to CDI and Bean Validation as the best examples).
If you ask people, the winner is not clear at all. Like in my article about the comparison of Java frameworks, there are the "hype" followers vs the conservationist, the "old" vs the young. Like a battle of generations.
Actually, maybe the truth is in the middle. Annotations are indeed great for simplifying your code, but should maybe be limited to the more "static" parts. Things or settings that depend on deployment, data sources,...can better be declared in XML. DI is much more readable when all of the players are central in XML, whereas transactionality and cross-cutting concerns for instance could better be put via annotations.
Conclusion
Often a good compromise is the way to go. No "winner", but a win-win situation. Maybe even other methods will show up. Only the future can tell what was right.