A part of the Java community seems to have a serious case of the anti-XML disease. Anywhere they see a snippet of XML they immediately condemn it, torch it and rip it to shreds without looking at the meaning and the purpose. Hell, it's XML, so it must be bad and totally inappropriate. It's obviously bloated, not needed, over-architected and not offering anything worthwhile besides configuring items that nobody wants to customize.

People, XML is just a language. True, it has been abused a lot in the past, and so have many other things in your development toolkit. The key message here is separation of concerns. I guess we pretty much all agree on the fact that you don't want a single agglomerate of code where all possible concepts bleed together into an unmaintainable mess. Otherwise we would all still be writing pure JSPs with scriptlets that perform direct JDBC access, view handling, and direct data manipulation without any kind of domain model right there.

I don't care the tiniest bit about XML itself, but I do care about reusability, maintainability, clarity, consistence and de-coupling. I want to express contextual information that is not related to the actual logic of my components somewhere else. I also don't want to have to change my components when I reuse them or when the context in which they are used evolves. Intelligibly externalizing all the 'glue information' might be a small overhead to pay initially, but I've always been very happy that I did a few months further down the road. Remember, development is not solely about getting somewhere to fastest way possible. You wouldn't be using patterns like MVC, IoC, Service Locators, ... then, would you?

I strongly urge Java developers to look at the purpose and the meaning of the XML that they're about to crucify, and by that I mean the larger scale, long term benefits and not just the additional overhead of an overly trivial example. Consider what you gain from all the provided facilities from a maintenance and team development perspective. Isn't that what you do when you evaluate a Java API too?

Finally, XML really is just a language, I've successfully replaced many declarations with other languages like Groovy, Janino or even pure Java. Check if the underlying builder APIs are consistent and well designed, and look past the brackets, the tags and the arguments of what is often just a facade. It's a shame to judge a entire technology stack by the frustration that has been associated with something as trivial as a declarative language.