The BileBlog

Recently I’ve had a need for an IoC container to bless some components with some good old fashioned dependency injection lovin’. So I thought that given how many people out there use pico/spring/hivemind, they can’t be THAT bad. Picocontainer in particular seemed very promising, as it seems to take the embeddability aspect of ‘lightweight’ containers to heart, and does not mandate xml files from bizarroworld (Note to all ‘embedded’ library developers, if your lib mandates a logging framework, or a specific xml file, then you don’t know jack about embedding. I hope you’re listening Mr Hivemind).

It also has next to no dependencies, which makes the thought of depending on it (no pun intended) far less of a house of cards that is the usual case with opensores drivel.

Amazingly, even though I really, really wanted to use it, the damn project went out of its way to drive me away. It’s quite impressive really, I go in wanting to use a product, all but committed to it in my mind, and yet, through the magic of a certain unique touch of poo, was driven away and forced to seriously consider other alternatives.

First, given that I know how OSS works, you’re likely to be told to get the CVS version if you ever run into any issue at all. Being an adventurous sort and intimately familiar with cvs, I thought I’d do that from the outset just to save some effort later on. Here’s where the first touch of genius pops up. The cvs modules are called delightful names like ‘java’, ‘php’, and so on. Despite being consummate java developers with many years of experience and loudmouthed opensource prima-donnas, the authors somehow managed, in a fit of mass insanity, to completely forget how cvs module names work. Sure, I can change the name of the directory once I check it out, but really, why force that extra step? How hard can it possibly be to pick non-spastic cvs module names for an open to the public project?

If only that were the only issue. My hopes were further raised by seeing a build.xml there, tempting me with its easygoing ways and no-nonsense approach to life. So I type those magic three letters, and….hrm. Big blowup since I don’t have junit. Rather odd to be defining a junit task for just compiling, but ok, I can live with that….now lets try again…

Ohdear. Having just installed junit, I bet you’d never ever guess what ant tries to do next. Ready? It….downloads junit. After downloading junit, it downloads ant 1.5, THEN downloads ant 1.5 optional. Then, just to be safe, it downloads junit again. Having downloaded that mindboggling set of ‘dependencies’, it then simply blows up and refuses to build anything.

The maven wankstains like to brag of how maven autogenerates build.xml. Come on, has this EVER worked? Having a build.xml there that nobody has even bothered run is incredibly offensive. It’s the sign of an astoundingly lazy mind. A desperate hoister of featureturds with no thought or consideration or indeed…testing! Perhaps this hasn’t been testing because testing ant is just not possible within junit, and therefore is a terrible idea that will result in insta-smiting from the junit gods.

Nevermind, I’ll have to resort to the latest blessed downloads (basically, the last time some random developer got drunk and thought it’d be hilarious to put out a release). In the meantime, I’ll browse the docs and get a better feel for this beast.

The docs are, to put it mildly, the worst documentation I have ever seen for a project in a very long time. This includes projects that have NO documentation, which at least says more than what the pico docs offer.

For one thing, the documentation is all about the religious beliefs of the authors. They proclaim they support setter injection, but expend so much effort telling you off for thinking that way. Every other line links to some antipattern that this group of lackwits has thought up. At some point they even proclaim that soon there will be a ‘componenthaus’ site that offers pico components to download! (har har, how well is that coming along?)

The ‘relative volunteering’ section also seems to somehow totally miss the point of the project. No doubt as a result of another drug laced late night binge, someone chirped up with ‘components! That’s the future! pico is all about enabling component repositories!’ and the other clever clogs in their opium den of filth somehow latched onto this, and thus was born this sad pitiful page.

Of course, all the parts that actually merit documenting have not been. Setter injection requires that you plop in a ComponentAdapter. That section of the documentation is, unsurprisingly, blank. It’s really astounding what people will put up with from open source docs. The pride and acceptance that the community at large takes in these pitiful droppings is akin to a parent proudly displaying the pathetic crayoning of their spastic three year old child to all and sundry. Just image the outcry if a commercial vendor had the gall to put out documentation with a section left completely blank (and leaves it blank for the next year or two).

Similarly, for all the bragging of container hierarchies, the ‘documentation’ offered merely punts you off to the nanowar project, which just talks about itself and you’re forced to infer how that actually relates to component hierarchies and how they might apply in different situations (hint to doc authors, documentation-by-example should come AFTER documentation-by-documentation). That nanowar page also merrily discussed nanocontainer, which is the first we’ve heard of this term (if you, like any sane curious person, were merely reading picocontainer docs). Although there is a particular stroke of genius here, where, in a totally deadpan tone, the inspired author suggests that nanocontainer is best bootstrapped through groovy code in a web.xml parameter.

Of course, the lunacy doesn’t end there. The FAQ goes on to give us more side splitting examples. Witness the helpful question ‘Is a single Uber|Super|BorgCollectivePicoContainer in development? Something that can do all things for all people in all deployment situations?

‘

Honestly, what the hell could the answer to such a question possibly be? You could substitute ANY product for this and still ask the same ridiculous question and still get the same pointless answer-that-has-words-but-says-nothing.

What’s freaky about this project is that the end result does work, and works with some measure of success. Using it though requires turning a very very blind eye to any documentation or non-code emitted by the authors. It’s almost as if the project’s success is through some bizarre cosmic accident. Just another freak output of the thousand monkeys at a thousand keyboards.

This entry was posted on Monday, March 28th, 2005 at 10:40 am and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.