Over the last two weeks there seems to be have been a sea change in the view of configuring applications using XML. The phrase ‘XML Hell’ has been around for a while, but criticism of this style of configuration seems to have peaked and reached critical mass. You just have to look at the list of blogs on JRoller alone to see how ‘hot’ this theme is:
- Stephen Colebourne – Configuration in Java – It sure beats XML!
- Craig Walls – Guice vs. Spring JavaConfig: A comparison of DI styles
- Niclas Hedhman – Becoming XML free
- Benoit Moussaud – La guerre des conteneurs IoC est repartie
and last and to be honest, least (specifically as it would appear he is a contributor for Guise) …
The problem I have is that XML configuration, specifically used in frameworks such as Spring and Hibernate, solved problems which have not gone away. Yes, you can now configure applications using annotations so instead of central configuration xml files you bloat your code with imports and annotations. You also end up with de-centralized configuration in each of your classes. Yes, for certain types of configuration, and I would proffer transaction via AOP to be one of them, this makes sense. But de-centralized configuration does not make a great deal of sense for the majority of cases (ORM, etc).
So Google have stepped in with Guise, pronounced ‘Juice’. Now seeing as this Guise could be Bile, I am less than happy to swallow it. For a start whereas with Spring the intention, if not always the practice, is to make the configuration as non-invasive as possible. Their intention is to have none or very little dependency on the underlying framework, Guise in comparison makes you dependent on it from the get go. Not only are you going to bloat your imports and code with annotations, you are also required to re-compile your code for every change to the configuration. Yes, I think that will make a big impact on my development cycle. This is something that has been put into sharp relief by the likes of RoR whose development to deploy cycle is infinitely faster than Java even using XML configuration.
As way of an example; I develop fairly large scale applications, usually with Maven 2 as my build (or comprehension!) tool, but regardless I have always (or at least in the last 5 years) segmented/separated the areas of concern into small and reusable deliverables. Since using Spring, each and every deliverable contains its own context and by and large none of them exceed about 50 to 80 lines, including white space. On average my applications have four areas of concern; Domain, DAO, Service and some form of client layer (Web, Rich, SOA). There are on average four context files with no more than 360 lines of XML between them. This is hardly bloat and it is nicely human readable.
Now if for every tweak I make to the configuration I required a re-compilation, I would spend an extra 1-2 minutes of compilation for each iteration. Sure, I would be less prone to making errors in my configuration as mistakes would be detected at compile time, but using a good XML editor limits those mistakes using the Schema with Spring 2.
I see no gain in moving from Spring to Guise or any of the currently suggested solutions. In fact at this time Guise is only a partial competitor to Spring, as its own documentation states. So I would end up with configuration in Spring XML, Guise annotations and AOP annotations. That is just plain nasty, and more than justifies the hit of the supposed XML bloat.