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.
March 14th, 2007 at 6:47 pm
first?
March 14th, 2007 at 7:17 pm
Bring back the fookin’ properties file I say!
No but really, I’m in agreement here. The XML stupidity hasn’t only infected Spring but almost every framework I’ve worked with for the past 2 years. You have your Hibernate XML’s, your Struts 2 XML’s, your Struts XML’s etc… Not to mention I have to restart my servlet container every time I rewrite XML config files, why can’t we just annotate that shit and skip XML configuration as the de facto standard?
March 14th, 2007 at 9:28 pm
well said!
March 14th, 2007 at 10:11 pm
This is Grade A Bile, the kind your sick readers have become accustomed to. Thank you for the fix.
March 15th, 2007 at 12:22 am
I like how Rod Johnson has now taken Marc Fleury’s place as emperor of bileworld.
March 15th, 2007 at 12:52 am
we all know that, however every new technologii is using xml heavy :( maybe when JDK5 will be final(for me is still beta since i can only use it at home) things will change with annotation. I bet is hibernate would drop xml configuration and use only annotation JDK5 would be used more often.
March 15th, 2007 at 1:55 am
Ok. So whats wrong with PicoContainer?
You can configure your dependency
in Java code and it can run in JDK 1.4.
Running in JDK 1.4 may not be important
for you but many people will disagree.
March 15th, 2007 at 5:17 am
[getting onto appropriate fucking character]
There are solutions to the XML hell. Fuck, it ain’t even that hard to think up. Just have a
“service” running as a plugin or similar that synchronizes between the .xml file in question and the his mate, the “.xml.java” file that inherits form a class molded from the DTD of the .xml file.
Then you can have any fucking “public static final String” or enum refactorable values with normal Java code doing even the most messed up and intertwined XML configurations files strongly typed. And the best thing is that you can go both ways, as I know you generally like it to be Hani, and edit the XML file or the xml.java file and have it synchronized to the other one.
It’s not that fuck hard, just do it instead of complaining about your personal anal itches! ;)
[getting out of character]
Btw, what’s up with the math to post. Are you censoring stupid people? Obviously I tricked it.
Cheers,
Mikael Grev
March 15th, 2007 at 5:44 am
“Your configuration bean bullshit still doesn’t cut it, dependencies are best expressed where they belong, in the damn source code itself.”
Too damn right. Why can’t everyone see that?
So, in your not-so-humble-opinion, has Guice “got it right”?
March 15th, 2007 at 5:46 am
definitely agree, excellent post!
March 15th, 2007 at 6:05 am
The key benefit of using xml to configure the application is that it creates and maintains over time a clear separation between the implementation of a bean class and its use for a particular purpose. I’ve tried putting configuration in java files before, and it ends up in a mess with no separation between implementation and configuration. People with little self dicipline, such as myself, needs a little guidance from having the configuration in clearly separated files in a different language. Hardwiring the configuration into the source code with annotations effectively makes reuse of the class’s business logic in a slightly different configuration impossible and voids most of the benefits gained from aspects.
Fixing a small config-glitch in a text file on the server is also much easier than a full edit-build-install-cycle.
That being said, xml may not be the best “programming language” for scripting the startup of the application. It does actually stink, I’ll give you one for that.
March 15th, 2007 at 7:10 am
Stop hating and start doing something! Oh wait… Aren’t you a Guice committer?
March 15th, 2007 at 8:46 am
I laughed very hard.
March 15th, 2007 at 10:30 am
clear separation between the implementation of a bean class and its use for a particular purpose
Well IMHO encourages bad practices and you’re always lost searching for an xml file, value somewhere…
I don’t like Struts with 1000 conf file, I don’t like J2EE.
Annotations is fine, closer to the code.
I don’t like neither the xml of ant, it’s a mess.
XML is evil. Yaml? I don’t know.
Properties files? At least with eclipse u can follow where the property is used.
Java files for configuration? No, sucks.
Let’s invent something new.
March 15th, 2007 at 1:23 pm
XML is just about the worst thing for configuration files. If your configuration is so obtuse as to actually benefit from XML, you have other problems. That said, you don’t have to go with a rebuild either. JMX is a wonderful API you should check out sometime. It allows for easy systematic access to your runtime variables via any interface you’d care to build on top of it.
As for my impressions of Spring after having been forced to use it for the past 3 years: it sucks. Not necessarily Spring itself, but its use. (Actually, I’m under the impression that Spring is a solution in search of a problem, but that’s another whole post)
The primary reason I’ve seen it used is for testing (mocks and such). Now correct me if I’m wrong, but production code should never include “test” code, and if the only purpose of “Springifying” your code is for testing, then Spring is test code and shouldn’t be in your production code. QED.
March 15th, 2007 at 1:41 pm
XML Rules!!!! I think we should only write xml and use an xslt to transform the xml into java source code. Just kidding!.. Great Bile! Ever notice that Rod Johnson’s name is the same as saying Penis Penis.
4 + 94 = 98… had to bust of the calculator for that one.
March 15th, 2007 at 2:09 pm
damn, what banks are using jdk5? here we’re still stuck with jdk1.4
March 15th, 2007 at 2:23 pm
Amen to that.
March 15th, 2007 at 5:40 pm
Hibernate can be configured in java, xml, annotations or a combination of all three. Some of you need to do your homework.
March 15th, 2007 at 8:49 pm
“damn, what banks are using jdk5? here we’re still stuck with jdk1.4″… yeah same here i’m consulting at 2 and both are java1.4. Agreed on xml stuff. We should all use Guice it handles everything spring does right? pfft.
March 16th, 2007 at 8:14 am
package opensores.crap
public class ShinyBauble {
public ShinyBauble(String perpetrator, boolean redundant, boolean annotationInfested, boolean lateToTheParty) {this.perpetrator = perpetrator;}
private String perpetrator;
public String getPerpetrator() {return perpetrator;}
}
package jroller.obnoxious.bloggers
public class PottyMouthedHypocrite {
private java.util.List listOfBuddies;
public PottyMouthedHypocrite(){ listOfBuddies = java.util.Arrays.asList(new String[]{”Bob Lee”, “Jason Carreira”, “Cedric Beust”}));
}
public boolean likes(ShinyBauble shinyBauble){
return listOfBuddies.contains(shinyBauble.perpetrator);
}
}
March 16th, 2007 at 9:25 am
according to this blog-entry by rod johnson spring can be configured in java too. http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/
since the guice hype started, i wondered how it compares to springs java configuration feature?
March 16th, 2007 at 10:35 am
Please have a look at http://beanlet.org. It is a Java Application Container that solves the issues raised by this excellent blog :-)
I’m just about to release version 0.4. A 1.0RC version will follow soon!
March 16th, 2007 at 10:40 am
I’m sure Google are very grateful for this pimping.
Hani:
Worked on an app server: biles JBoss
Contributed to XFire: biles Axis
Contributed to Guice: biles Spring.
Astonishing.
Seriously though, I quite like Guice, but it really is fundamentally the same thing as autowiring (with one spring context per guice module)
It seems to me that you can only have one implementation of an interface which is exactly the same as autowiring (unless you want to use some kind of weird custom annotation stuff (not really documented of course)).
The Guice documentation is fucking woeful. One page which doesn’t even include a complete basic example.
March 16th, 2007 at 12:35 pm
I ran to the 7-Eleven today - no pain. I order 2 super slurpees (1 red, 1 blue). On the way out, a ran into a couple of Ho’s - picked em up for a little schizzlin of the nizzle. Now, I have some pain in the nizzle. I’m hoping this pain will go away soon or the missus is going to have some questions for this nigguh.
Rick Hightower
PS: Does anybody know exactly what I’m trying to say with my job graphs? http://www.indeed.com/trendgraph/jobgraph.png?q=java+jsf%2C+ruby+rails%2C+spring+mvc%2C+webwork%2C+struts2%2C+tapestry+java
March 16th, 2007 at 3:15 pm
I’m surprised no one has written xdoclet or annotations to generate the spring xml automagically when the code is built.
Oh, wait, they have…. http://www.google.com/search?q=spring+xdoclet
March 16th, 2007 at 3:25 pm
Makes sense, but then - there are so many things messed up in Java/J2EE that Spring with its bloated XML is hardly a major one. It is, indeed, annoyingly overrated, though.
I loved the remark that the same dudes that cherished EJB 2.x yesterday are praying hardest to Spring, now. Right to the point! :)
March 17th, 2007 at 1:11 am
Once Spring gets annotations and splits up their distribution into more manageable and JDK sensitive parts - which is bound to happen - it’s going to kick ass.
Even right now with the XML as it is, it’s still completely fine. Yes, annotations would be better but you got to be a pretty choosy SOB to not use it just because of that.
Why is the XML revolting to you? Are you writing your spring beans in notepad that you get confused?
Also, I like Guice but it’s got a long ways to go before it challenges Spring as a true alternative - as you might already know.
C’mon you could’ve picked something better for this post.
March 17th, 2007 at 8:58 am
what i can say after reading this fukin post is that if u dont like anything about spring framework you just keep your dirty big ass away from it,instead of spitting at other people’s work spend some time watching your own work. And if you dont have anyting important to blog about then keep your mouth shut. We dont want your expert opinion on this topic. We use what we like and don’t what we dislike but we don’t do negative criticism
In the end do us a favor all you (fucked by xml dick), just dont fuck around for a while
March 18th, 2007 at 1:59 am
Mr. annotations JSR hates spring config. Surprise surprise! You cna use spring config to extract items you want into properties files or even embed the properties format in the xml itself.
There’s one key thing you don’t have to with Spring that you have to with annotations - RECOMPILE. So much of coding these days is configuration, so having that crap extract to xml is fine with me.
Looking at Guice it gives an ok impression at first, but I can see guice users being very random in how they use it, whereas spring apps suggest their own organization.
March 18th, 2007 at 10:24 am
Ha Ha !
Spring remoting/orm/dao/jdbc/MVC/webflow/…, all total pile of crap.
Feels so good when you see you’re not alone, in the hate-spring team.
Down with Spring XML hell !
March 18th, 2007 at 2:15 pm
“”damn, what banks are using jdk5? here we’re still stuck with jdk1.4″… yeah same here i’m consulting at 2 and both are java1.4″
Same here. WTF?
March 18th, 2007 at 4:09 pm
Hi Guys,
Take a look at this article, on why XML is such a bad choice for so many things.
http://www.sdtimes.com/article/column-20060901-05.html
Basically I have always found XML a good alternative to RDBMS, when it comes to storing simple hierarchical data. As a matter of fact, I use XStream a lot, and for this very purpose.
Other than that, if you are using XML to describe build, document exchange, program flow and things like that, it fails miserably.
That’s why I have always hated ANT, Workflow Engines, BPML, BPEL and like, as they have taken what is best described in code (control flow and logic) and put in XML files.
In the process, they have invented these revolting and obnoxious mini programming languages, using XML syntax.
March 18th, 2007 at 8:39 pm
Has Bill Berk hijacked Bile Blog?
Sincerely,
His concerned Dad.
March 19th, 2007 at 4:25 pm
It’s always funny to see how xml based configuration mechanisms get bloated by each new version, just to introduce semantics which mimic a “real” programming language and wouldn’t be necessary if more work would be done with pure java.
That’s the reason why the HiveMind 2 IoC container features annotated modules for service definition and wiring:
http://cwiki.apache.org/HIVEMIND2/newin2annotatedmodules.html
March 20th, 2007 at 11:28 am
Spring isn’t a framework by any accepted definition of the term. It’s a collection of kludges and workarounds collected under a single umbrella.
March 21st, 2007 at 2:15 am
Making personal attacks on people is pretty childish. Using the amount of foul language you do is a bit pathetic - like a teenager who has been taught some new words by his peers and is keen to use them.
Rod J and the guys at Spring are doing a GOOD job. Sure, they could do better - we all could.
However, they have contributed more to the enterprise Java space that most of us will in a lifetime. They have brought IoC into the mainstream. In the corporate environment that I work in I see people using Spring to great effect: better componentisation, greater testability, better documentation, easier configuration.
I am sure that Guice is great and works well for Google, but if it requires annotations and rebuilds to rewire some components - well that sucks just as much as XML. Maybe more.
It doesn’t mean that it can’t do the job. Sure it can. I doubt that its corporate takeup will be anywhere near Springs takeup. People need to be able to change wiring easily.
March 26th, 2007 at 2:00 am
[...] 3rd party Jars end up being OSGi modules too. Spring has the completely opposite view of XML than some people. He’s calling Java messy and complicated and the example he gave was having a Spring config [...]
March 28th, 2007 at 10:59 pm
Greater testability, Better Documentation, Better Componentisation, Easier Configuration != Spring.
Greater testability, Better Documentation, Better Componentisation, Easier Configuration == Good Object Oriented Design using proven principles (Liskov Substitution Principle, Open Closed Principle, Separation of Concerns etc.).
Im with ya Hani… givem hell… you should see what mess Spring has caused on our project. Its been so over-injected that the app looks like a seasoned junkie’s arm (and also performs like one too).
March 29th, 2007 at 7:18 am
[...] - The BileBlog : XML is for girls Aside from Hani’s usual obscenities, or perhaps due to them, he’s produced quite a gem [...]
April 12th, 2007 at 7:48 pm
> Greater testability, Better Documentation, Better Componentisation, Easier Configuration != Spring.
Are you mad? First of all componentisation isn’t a word so go back and figure out what you’re trying to say. As for testability, Spring makes it EASY to test. Maybe you just don’t know how to do it, but you can introduce mock implementations with ease and compartmentalize anything you want. I don’t even know what documentation has to do with this.
April 19th, 2007 at 10:54 am
Is the world full of idiots ? Yes. So a Spring project you worked on is a mess therefore Spring is to blame. Cretin.
No framework in the work can stop the idiot architects from producing a complete and utterly impenatrable code base.
Spring included. Also to suggest that the EJB 2 fan boys are the Spring fan boys is way off base. I think
Hani is secretly a great admirer of Rod ;)
April 20th, 2007 at 8:52 am
Great bile. XML wiring has been passe for a long time now, and annotations, EJB3 definitely deserves credit in this transition. But I do applaud Spring guys for turning up the heat on Sun (no pun intended), giving unfortunate EJB2 souls an alternative during certain period in Java history. If it wasn’t for that heat, EJB3 probably would not have been created. So thanks to Spring, but, at this point, no thanks.
May 8th, 2007 at 7:58 pm
What XML? Grails will save Spring.
July 28th, 2007 at 3:13 pm
Hmmm … I dunno. A long long time ago I learned how bad it could be to embed SQL in my code. Now part of the community seems to be in love with the idea of embedding configuration metadata in my code.
I’m not sure why I’d want to do that. I’m pretty sure I would prefer to be able to change my app’s configuration at runtime rather than compile time.
I’m also not sure why describing my dependencies with annotations is going to be easier to understand than describing them in XML files. I imagine I will have to look at many more files to see all the annotations … hmmm … why do I find myself thinking that this is the same problem we face when defining complex workflows ? Might we need the same solutions for both challenges ?
I would not expect that Spring has implemented the ideal way to do this - but why would I expect that ? In my view people speak as though Spring should be the definitive source of so many things rather than what it is - a pioneering framework. I would not expect Spring to be the definitive source of anything. I would expect it to be an awkward implementation of some good ideas derived from some even more awkward implementations of some good and bad ideas that came before.
Speaking of good and bad ideas, I cannot forget that the guys who are arguing so strongly for an annotations-only approach right now are the same guys who brought me EJB 1 & 2 before. At the time those were groundbreaking accomplishments, and I don’t agree with the kind of criticism the basic concepts have drawn over the years, but I do keep in mind that they hung on to some really bad ideas way too long until, essentially, the Spring and Java community forced them to change. They were wrong then and I’m not sure they are right now.
As an aside. my team leader came up to me the other day with a cool possibility - something called JSQL, he explained. Apparently you can use it to put SQL right in your Java code and it has good performance. I hid the body in the small closet reserved for long-term planning and risk assessment activities. It should be years before anyone goes in there …
July 17th, 2008 at 11:11 am
“I’m also not sure why describing my dependencies with annotations is going to be easier to understand than describing them in XML files.”
you must be joking!
Better to use annotations during development, and use some kind of tool for externalizing them to an XML file if for some reason you really really think that makes sense, you can do this for example with JPA annotations and some code from Oracle.
July 17th, 2008 at 11:12 am
here’s another comment: what is easier to manage, an application with 100 classes autowired together by the container when they’re needed?, or checked at compile time? hmmm……