Some people find value in having centralized, declarative configurations of XML files. However, many of the things in those files are not configuration and they do not change after development. Having a centralized configuration is usually only valuable in small projects. Still, some people find comfort in knowing how the configuration is wired together as a whole, even though the same "wirings" are mainly just duplicated by the dependencies in the code. Developers who use full autowiring with the @Autowired
annotation for Spring have no problems
leaving their external XML configs behind.
One of the most important reasons why someone would use autowiring (@Autowired) is to have one less abstraction in your system. Even though it might be a simple layer, thats one less layer of complexity. When it removes a full layer of abstract indirections, the bean name is essentially gone with the name still preserved because of XML. At this point you can just wire the "Foo" interface directly into your bean and the run-time profile will choose an implementation.
Now you can work with code while tracing implementations and dependencies. When you encounter an autowired dependency in the code you just hit the "go to implementation" key in your IDE to bring up the list of known implementations. Many times there will be just one implementation that takes you straight into the class. With full autowiring, you'll know exactly which implementation is being used, which isn't always true for XML wiring.
In plenty of cases, XML configurations are full of inconsistencies and it's hard to tell which ones are intended and which ones are not. Full autowiring works really well because it's built for a common pattern that most use cases follow. You rarely need to use qualifiers in your configuration because there are other ways to solve these situations. The only disadvantage is that you will need to change the way you code slightly to make it interact more smoothly with autowiring. For example, a customer repository no longer implements the generic Repository<Customer> interface. Instead, you can write an interface CustomerRepository that extends Repository<Customer>. Also, you might need to tweak your coding for subclassing, but the side effect will be stronger typing.
Another gripe might be that you can only get this functionality with the Spring Framework and not in standard Java. For that we'll have to wait and see if it gets included in a JSR, like JSR 250: Common Annotations. Some don't know if this is a good approach in the long run
, but SpringSource is using this approach in almost all of their systems. It's not hard to change your systems to autowiring with annotations either. It integrates very well with XML.