The Path to Zen

Clean Desk, Messy Drawer

My wife, despite all of her loveliness, does have her own ways of annoying me from time to time, one of which being how she cleans up our office desks - she would sweep everything off the surface of the desk and into the two top drawers, shut them close, and claim “Ta-da! See how neat it looks now!”

Sadly, in the recent years, I have been observing more and more of this “let’s move things around and call it clean” approach being applied in the software development community. What finally triggered me to put down my rant in this blog is the Spring Simplified with XBean proposed by Craig Walls recently.

I was, in face, perfectly OK with the first part of the article: Spring context files tend to be verbose - hear, hear; We could use autowire and XML name space to simplify it a bit - sure, k:HolyGrailQuest is definitely more intuitive than the FQN of the same class, I can buy that, even forgetting the price of enduring some extra API dependence on XBean for a moment.

And then there it came “the drawer”, in this case being a property file:

…
In the example above, the XML namespace was a “java://” URI and XBean assumed some simple conventions for the XML tags and attributes. But if the namespace is an “http://” URI, it can be used to lookup a properties file that guides XBean to alias class names and property names into custom XML tags and attributes.
…

After applying the property file (and in any real application I wouldn’t be surprised if there ends up being a number of them scattered all over the classpath), the original Spring context file is reduced, not only in terms of size, _but also_ in terms of the information it conveys. Granted, with all the verbosity in the original context file, it would take me a while to get a hold of how the beans are configured, but at least I still could. And the verbosity would become much lesser of an obstacle after the initial learning curve. Now with all the actual class names being externalized (again) into a separate property file, I can stare at the context file for all day and still have no idea as to which concrete class a bean definition will be instantiated with.

Towards the end of the blog, Craig gives a before/after comparison of the two Spring context files that shows the “simplification” cuts the size of the file to half. My argument, however, would be that a true comparison should be between the original file and the simplified one plus the property file.

And even that would be ignoring some hidden cost introduced - it’s always harder and hence less productive to reference back and forth between files than to work within a single one. In this particular case, I don’t really think the cost is justified. while Spring context files are indeed verbose, and _can_ become a real mess if you are not careful, somehow it has never become a problem for me in any practical sense — maybe thanks to Spring’s own ability to load and merge multiple context files into one definition, its ability to import context files into one master, and the Eclipse plugins I have picked up such as Spring IDE and XML Buddy.

Of course, as I said in the beginning, this rant of mine didn’t just come from this one incident. People are trying to clean up the desk by sweeping the mess into drawers on much larger scales. For instance, initially we didn’t feel like hardcoding Web application control flows, URL bindings, and all other sort of volatile mass into Java code, so we came up with various formats of XML files to dump those things into. Then annotation came along, so we somehow felt it would be cool to move those things back into Java code, only in the “meta data section” this time. And then some other folks developed tools that “allows you to externalize the annotations into XML or property-based configuration files.”

Back to Craig’s idea on simplifying Spring, I would like to conclude this article by a one-dollar wager - as soon as there are enough folks going along with this approach, I bet some of us will go ahead and develop “an extension to XBean that supports specifying Spring bean aliases and class names in XML files instead of the rather limited properties format.” Now, any of you care to take me up on this one?