Judging from the response, most people still disapprove of completely replacing XML, which is expected. I personally prefer to replace the bean definition of XML with code, which is more about personal preference, and does not mean that people who disagree with me are wrong.
Let's start with the advantages of code relative to XML:
1. More concise, compared to the "syntax" of XML, Java came to be more familiar
2. Type safety, to a greater extent the Java static language features
3. More friendly to refactoring
Besides the possibility of replacing XML with annotation, it seems unlikely at the moment, and there are the following limitations:
1. Language and culture of Java
I don't know which language is more dependent on XML than Java, especially web development. Before JDK5, there was no annotation era, and XML was used to document some supplemental semantics, and there seemed to be no more ideal solution. These years used to use everyone's habit, so no one to question. Look back at the usual use of the various large and small framework, in addition to Bob Lee developed Google Guice, no one from the original design to throw away the XML, under the influence of Java mainstream culture to come up with such "non-mainstream" work, no wonder he claimed Crazybob. Fortunately, these conditions are slowly improving, annotation and the COC and other ideas are accepted by more and more people.
2. Limitations of Spring itself
The schema and namespace introduced by spring2.0 greatly simplify the definition of XML beans, such as <tx:annotation-driven/>, and a simple line opens the ability to configure transactions with annotation ( Remember how many lines are required to configure a transaction when spring1.x? )。 How do you do it with @Configuration? This time only into the details of spring, find <tx:annotation-driven/> Registered all the beans, one by one in the Appconfig.java manually defined. I have thought about writing a plugin to solve this problem, that is, the code to define a simple bean can be implemented namespace such a function. Later on in spring, Jira discovered that spring3.1 was about to provide such support by adding the following advanced configuration features to the Java-based configuration:
* Enabling Annotation-driven Transaction management (<tx:annotation-driven/>)
* Enabling Annotation-driven scheduling (<task:annotation-driven/>)
* Enabling AspectJ auto-proxying (<aop:aspectj-autoproxy)
* Enabling domain object DI with @Configurable (<aop:spring-configured/>)
* Enabling Property-placeholder Replacement (<context:property-placeholder/>)
* Enabling AspectJ Load-time weaving (<context:load-time-weaver/>)
* Enabling MBean Export (<context:mbean-export/>)
* Enabling component Scanning (<context:component-scan/>)
* Performing JNDI lookups (<jee:jndi-lookup/>)
* Looking up local and remote stateless session beans (<jee:local-slsb/>; <jee:remote-slsb/>)
So this problem will be solved in future releases.
Summary: So I think java-based configuration is going to be a trend. Ashamed to say that languages such as Python and Ruby have not done so long ago? Look at the Django, rails, the configuration is not all in their own language to write it? How can we be absent when everyone is playing so High,java?
spring3.0 using annotation to completely replace XML (cont.)