Why annotation configuration is preferred than XML in spring ?

[vishnu priyag]

Hi,

Consider this example

@Component
class EmployeeService {

       @Autowired
       @Qualifier("jdbc")
       private EmployeeDao employee;
        
       ---------------------
       ---------------------
}

@Component ("jdbc")
class JDBCEmployeeDao implements EmployeeDao {
       -----------------------
       -----------------------
}

@Component("hibernate")
class HibernateEmployeeDao implements EmployeeDao {
       -------------------------
       -------------------------
}

I have this doubt since very long when people say java based configuration is better than xml.
In the above example, when i want to change the dependency of employeeDao from JDBC to Hibernate, i need to update the @Qualifier("hibernate"),
and then have to compile the java class and then run it.
We moved from normal java new keyword to DI to decouple the dependencies and change the dependencies without change in code. But in above scenario, change in java code and recompiling is needed.

But xml configuration avoids this recoompilation.
Then why people still prefer annotation based over xml?

Does change in annaotation data not require compilation?


Thanks in advance.

[Tim Moores]

One benefit is that the information is in one place, the Java source code, rather than in two.

Another benefit is you don't need to change XML files. It is very unfortunate that people got the idea that XML should be human-editable, just because it is human-readable, and we consequently got lots of XML config files. It has taken us many years to get away from that, and the sooner they're gone, the better.

Also, I don't see avoiding recompilation as an especially desirable goal when it comes to making changes. It's sometimes nice not to have to, but as long as you're changing Spring Components, you're in development mode where compilation and deployment are frequent occurrences.

[Stephan van Hulst]

For me one of the most important reasons is that the compiler helps you type the name of annotations and its members correctly, and auto-complete also usually tells me what valid values are for certain members.

With XML, your IDE needs to have access to an XML schema to help you fill in the configuration, and even then details are usually missing and you're left having to look up the correct version of the correct manual to figure out what you need to write.

[Rob Spoor]

No matter if you need to change the qualified injection in annotations or XML, you'll need to (partially) rebuild and deploy the application.

If you want to make the name more dynamic, then using qualified injection is probably not the best way. I'd inject a BeanFactory (usually the ApplicationContext), and use it to get a reference:

EmployeeDao employee = context.getBean("jdbc", EmployeeDao.class);

In this small example, the "jdbc" can come from configuration or somewhere else.

[Tim Holloway]

Quite a few systems - ORMs, JEE webapps, and so forth were configured and/or wired together originally via XML. There were no annotations.

This was a royal pain, since as Stephan pointed out, to fully define an object and its configuration, you had to edit 2 files at the same time and if you forgot to keep the one in sync with the other, you'd have to go back and debug it.

With Java 5, annotations were added, and the XML-based configurations were effectively deprecated. Now you only had to edit one file, not two.

But XML configuration isn't obsolete. Some options aren't closely tied enough to a class to make them eligible as annotations. Plus XML provides an override mechanism. The common/default configuration is in the annotation, but if you want to employ an alternative configuration, you can do it in XML, since XML overrides annotations. That way you don't have to touch source code, just the XML. XML is declarative, so it can be automatically validated in many cases. Plus you can't accidentally screw up program logic, because the XML contains no logic.