XML wiring is for girls http://jroller.com/page/fate?entry=xml_wiring_is_for_girls
The fact that XML is, basically, a steaming pile of goatshit is not news. Many many people know this now, yet you have an awful number of people eager to grab a hold of some xml and perform deviant sexual activities in it, around it, and in between its elements.
The problem is that there are some good ideas out there that happen to use xml. Even though xml has nothing to do with the quality of the idea, xml somehow gets credit.
This has become quite apparent lately when participating in some Guice vs Spring debates. The fact of the matter is, Spring's XML sucks unbelievable amounts of ass. Don't buy the bullshit hype of Spring 2.0 improving its XML so it's now all great. All it's done is made it plausible that one might not jab oneself in the eye with a big black ribbed for his pleasure dildo when confronted with it. I cannot believe that a sane person would think that the Spring 1.x syntax is fit to deposit a big dogturd on, let alone use in any application you'd care to be associated with.
I like Spring. I like the integration features it offers. The XML however is revolting. The IoC bits are about as pleasant as using a bucketful of Rod Johnson's moobjuice as anal lubricant. You either have to autowire (which is convenient but too magical as your project grows, not to mention fragile), or explicitly wire stuff in xml, miles away from the source code. Lets not even get started on how abysmal performance is once you're using a real project with more than 3 beans, or heaven forbid, wiring up actions at runtime. You could play many a game of soggy biscuit while Spring figures out who needs what, when, and why.
Of course, the situation is conveniently disguised by the fact that tools such as IDEA natively grok Spring's hellish configuration.
No doubt someone will counter with the fact that thousands of people use Spring and all is well. Yes, thousands of people also used EJB2, oddly enough the very same places that switched to Spring. What are the chances of all these venues suddenly becoming full of wise intelligent developers who from now on will only make sensible sane well considered decisions?
As a result, Spring is hopelessly fucked due to its success. It can't really drop support for crappy old JDK's (contrary to what everyone tells you, banks ARE using JDK 5 now), so will always be lumbered with its current idiotic configuration and wiring approach.
That problem makes it somewhat understandable that the Spring guys, in order to defend their fuckeduptheassness, deride annotations and proclaim that declarative xml goop is Rod's Holy Word. Go forth and write xml, Rod proclaims, and the unwashed masses go forth and positively ooze angular brackets. Stupid fucks. Still, all is not lost, in cases where it's possible to shoehorn annotations into Spring's archaic innards, they'll enthusiastically proclaim it Useful and Recommended, such as the @Transactional annotation.
The other common argument is 'you don't spend too much time in Spring's xml compared to time spent in your code'. Sure, I also didn't spend much time writing ejb2 descriptors either (xdoclet did it), yet everyone bitches about those. Why can't we apply the same standards to Spring?
Fundamentally, Spring has a tough time accepting that the world has moved on, and that its approaches are starting to look a wee bit outdated. Even EE 5 in many cases looks more modern and usable than some of its approaches. Thanks to its widespread use, they can, much like the JBoss people, maintain an insular world view where they're surrounded by sycophants who do nothing but bend over with a shiteating grin plastered over their sallow filthy faces.
So do yourselves a favour Spring guys, and stop being so obsessed with where you are now and with how much you can do with AOP (which nobody cares about, it's not 2004 anymore so move on), and instead look around with an open mind and embrace annotations like you'd embrace a Rod Johnson penis replica. Your configuration bean bullshit still doesn't cut it, dependencies are best expressed where they belong, in the damn source code itself.