Java Reference
In-Depth Information
1.5.2. Annotations versus XML
Prior to annotations (introduced in Java SE 5), XML was the only logical choice for applic-
ation configuration because there were no other viable options around, except for tools like
XDoclet, which was popular in many relatively progressive EJB 2 shops.
The problems with XML are myriad. XML is verbose, not that readable, and extremely
error-prone. XML also takes no advantage of Java's unique strength in strong type safety.
Lastly, XML configuration files tend to be monolithic and they separate the information
about the configuration from the Java code that uses them, making maintenance more dif-
ficult. Collectively, these problems are named XML Hell and annotations are specifically
designed to be the cure.
EJB 3 was the first mainstream Java technology to pave the way for annotation adoption.
Since then, many other tools like JPA, JSF, Servlets, JAX-WS, JAX-RS, JUnit, Seam,
Guice, and Spring have followed suit.
As you can see in the code example in
listing 1.1
,
annotations are essentially property set-
tings that mark a piece of code, such as a class or method, as having particular attributes.
When the EJB container sees these attributes, it adds the container services that correspond
to it. This is called
declarative-style programming
, where the developer specifies what
should be done and the system adds the code to do it behind the scenes.
In EJB 3, annotations dramatically simplify development and testing of applications.
Developers can declaratively add services to EJB components when they need to. As
figure
1.7
depicts, an annotation basically transforms a simple POJO into an EJB, just as the
@Stateless
annotation does in the example.
Figure 1.7. EJBs are regular Java objects that may be configured using metadata annotations.
