The java guys “don’t get it”

September 18th, 2007

Just bumped into the twelve best practices for spring xml configurations, and the first one is “Avoid using autowiring”:

The property names of the OrderService class are used to match a bean instance in the container. Autowiring can potentially save some typing and reduce clutter. However, you should not use it in real-world projects because it sacrifices the explicitness and maintainability of the configurations. Many tutorials and presentations tout autowiring as a cool feature in Spring without mentioning this implication. In my opinion, like object-pooling in Spring, it is more a marketing feature. It seems like a good idea to make the XML configuration file smaller, but this will actually increase the complexity down the road, especially when you are working on a large project where many beans are defined. Spring allows you mix autowiring and explicit wiring, but the inconsistency will make the XML configurations even more confusing.

I can’t understand this uncontrolled passion that java programmers carry for xml. Even with the introduction of annotations (in 2004 for god’s sake) there still an awfully lot of xml that you have to write. Write and smile! And write more than you’d need to, as they discourage any other way in the name of “increase in complexity” that you would get if you lower the xml on your apps.

Why is that? Any serious app must have the equivalent in java LOC in xml?

I think that my decision to support and encourage autowiring on MicroKernel/Windsor was the most correct one. You just have to define a behavior, something that is easy to predict, that makes sense, that even people that wont read documentation can “get it” and you’re fine without xml.

Categories: Java | Top Of Page | 4 Comments » |

4 Responses to “The java guys “don’t get it””

Eric Hauser Says:

I agree with what you are saying, but I wonder if that particle author only had experience autowiring byType instead of byName. IMHO, autowiring by bean name is a very poor approach because it requires you to look at the configuration to wire your properties and property name changes break your config. Autowiring by type is a lot less error prone.

I think RoR has pushed the Java community in general to go with convention over configuration. With support for schemas in 2.0 and the new annotations in Spring 2.5, I think that you will start to see less and less XML. Spring’s JavaConfig option and Guice definately take that approach.

http://blog.interface21.com/main/2007/05/14/annotation-driven-dependency-injection-in-spring-21/

http://blog.interface21.com/main/2007/05/29/customizing-annotation-configuration-and-component-detection-in-spring-21/

http://code.google.com/p/google-guice/

Out of curiousity, any plans to introduce an attribute based interpeter for Windsor?

hammett Says:

hi Eric.

> Out of curiousity, any plans to introduce an attribute based interpeter for Windsor?

What do you mean?

Eric Hauser Says:

I’ve just started evaluating MicroKernel/Windsor for a project by reading the documentation, so I might have missed something that is already there. The way I understood it was that there were two ways to configure the container 1) using the Kernel API 2) using the Windsor XML configuration. I was looking for something more like:

[Component(typeof(Transient))]
public class MyComponent {}

Then, when I initialize the container it could use reflection to autodiscover the components.

hammett Says:

It exists, although I dont like it much. Check http://www.castleproject.org/container/facilities/v1rc3/batch/index.html

Leave a Reply