The BileBlog

It’s been a while since a village idiot hat has been awarded. While this is by no means a promise of regular hat givings, in this particular instance the recipient is gagging for it.

The winner is HTMLUnit. HTMLUnit, for those who are unaware, is basically a piddly little framework that lets you create web requests, and parses back the resultant html/javascript and lets you click on things programatically to simulate actual users. It’s great (in theory) for end to end acceptance testing.

Thankfully, the name is a total misnomer. For one thing, it’s not about unit testing at all. Therefore, has nothing to do with JUnit. It wisely avoids the spastic route taken by things like xmlunit, which provides classes tightly coupled to JUnit.

The premise is a pretty decent one, it’s the implementation, as usual, which makes the baby jesus cry hot tears of rage and anger while biting off the nearest nipple.

It all started innocently enough. I have a rather complex page that the current version of htmlunit fails on. Knowing how the oss thing works, I knew I’d just be told to try the cvs version if I reported the problem. Thusly I went off to cvs (sourceforge, the first sin), and grabbed the festering pile of goatpoo.

First problem, I see maven crud splattered all over. My heart sinks as I see the 3 tongued kisses of death; maven.xml, project.xml, and project.properties. This cannot possibly go well. Amazingly, there’s a build.xml there too, so I might be spared. I’m not hopeful mind you.

My dismay was in fact well placed. The ant file is nothing more than the year old solidified wankstain that maven squirts out. It manages to die before compiling a single line (it tries to specify an output dir for javac that doesn’t exist).

As an aside, I’d like to know who wrote the maven to ant plugin. I have never, in all these years, seen such badly written buildfiles. Now I know maven guys are fuckwitted rumpranging ADD-ridden gizmowhores, but surely they can’t know so little of how ant works or of how it should be used. Even their callous disregard for users and the real world doesn’t go the whole way towards explaining the mindboggling incompetence of this build.xml.

To cut a long story short, the file is a herring sporting a horrific red hue. Making this thing work would require an impressive collection of miracles from all major religions.

So we’re onto maven. Running maven, of course, is always a great excuse for a day out, maybe catch a movie or two, and a nice dinner, while it figures out what day it is, what it should do about it, and how to calculate the worst and slowest way of running a few thousand tests.

Eventually, a feeble jar is farted out. Plopping said jar in my tests reveals a rather dismal result. Cookies no longer work across invocations.

Ohdear. Nevermind, I’m a java guy, I can debug this sort of thing. Armed with nothing more than an abiding hatred for java developers and a trusty debugger, I sally forth into the brackish waters that are the htmlunit source code.

Hrm, here we go. At some point, one of these gurus of incompetence decides that we should internally store a map of HttpClients, keyed by host url. Thusly can clients be reused and state preserved across invocations, for a given site.

Said guru however didn’t actually bother fix the thing that gets stuff out of said map. So while the key is now host + port, the blocks that attempts to retrieve things from the map does not include the port. These days, every url has a port, thusly, much wailing and gnashing of teeth ensues.

Apparently, this problem has trickled down to other lost souls who use htmlunit cvs, such as the canoo people, who also have the odd user bleating about cookies being ignored.

So the fix is simple. A few lines of code later and I’m ready to attempt the Herculean task of convincing maven to give me a jar. An outing, couple of movies, and dinner later, maven proclaims that some tests have failed. Hilariously enough, the ‘helpful information’ it gives me about this build failure is line and column information of the jelly script junit plugin that failed. Highly relevant I’m sure, just not to anyone except the halfwit author of said plugin.

So after a few days of pointlessly scrolling around, I find the culprit. It’s at this point that I completely lose it and start laughing hysterically. I can’t quite believe the test I’m looking at.

The test for http state works thusly: It gets at the class that holds the map. It uses reflection to access the (private) map, makes it accessible, and manually

puts a value in it. Having done so, it then calls a method which basically just reads from the map, and then compares the two.

It’s mind boggling to me that someone would write such a complex and awkward test to basically test that HashMap functions as a….map. Of course, this test and a dozen other just like it now fail, since the keys they use to do the manual insertion cannot exists anymore

. The change to the internals of the class being tested generate keys of a different format, so the test is testing a state that cannot ever, ever happen.

It’s sad and pitiful that things like this happen. It’s even sadder and even more traumatising that it’s not that rare, and is even more common than not. The collaborative effort of so much incompetence should not happen, it should be a freak accident that only happens very rarely, instead of daily, over and over again.

Paul Graham, yet again, proves himself to be yet another completely brain damaged spastic asshole who thinks, that because due to a freak accident of nature, he actually is different from the average slashdot teatsucker or has something worthwhile to say.

The man’s stupidity and ignorance is astounding. The crowd he preaches to is, if that’s at all possible, even stupider. Analogies to symbolise their relationship is perhaps the fundamentalist rabid Muslim preacher advocating death and destruction to a bunch of ill-educated rabid followers. Or perhaps the insane right wing Christian fatshit insisting that anyone pro-choice likes to eat babies to a group of midwest fatfucks intent on lynching brown people and damning random strangers to burn in a variety of hells for not accepting a baby jesus buttplug as their lord and saviour.

So it’s of no surprise to see a variety of blogs proclaim his genius. He is, after all, rummaging about to find their miniscule genitalia, and proceeding to tug it with enough force to elicit happy noises.

Where does one start? This man is so stupid, so ignorant, so eager to probe exactly how far up his own sphincter he can crawl that it’s amazing there’s anything outside of it.

Lets see, he claims that Firefox is better than IE because the people who develop it do it in their spare time and with religious fervour. Gosh, you haven’t spoken to a microsofty recently have you? These people have just as much passion, if not more, for what they do as the average dirty hippie whose poo you’re so desperate to eat. In fact, for a wide variety of opensores, you can get better service, better software, better documentation, and more professionalism overall by instead finding a commercial version that does the same thing. The converse is not true quite as often, or many more commercial endeavours would be killed by their open source variants. Certainly, anyone trying to select a product would be dimwitted in the extreme to choose one run by a hobbyist who is ruled by whimsy and mood and fears social contact and views professionalism as an insult to his artistic sense.

The blogging gibberish he spouts is also astounding. How can one man be so thoroughly ignorant and know so little of the real world? Give me a professional unbiased educated journalist any day over your average armchair blogger. Most blogs are a disturbing mix of zealotry, incompetence, ignorance, and randomly strung together smattering of incoherent prejudices. Lowering the barrier to entry does not improve quality, it lowers it. Some good stuff will obviously get in, but the vast majority will be far worse. Whether the former outweighs the latter is certainly not a forgone conclusion.

I’m also baffled by the amazing leap of faith he makes by assuming that if you work on opensource, you like what you do more than if you were paid (commercial). How many baby kittens did this filthy animal have to consume in order to achieve such enlightenment? If only he’d attempted a scientific approach and logical argument instead of mindless bloodletting, he might have actually preached to more than the choir.

The working at home stuff is also bullshit. Antisocial misfits perhaps work better at home. It certainly is harder than working at an office, it requires more discipline, but it is certainly not qualitatively superior to an office environment. The lone hacker bullshit works for certain things, but does not for most things you’d want to build a business out of. Maybe he lucked out by flinging feces to the wind and had them land at the right scat fetishist, but it’s certainly not a model for success.

In fact, a mere reality check is sufficient to prove that this man is so out of touch with reality that it’s amazing nobody has chained him up and tossed him in a mental institute for all the harm he causes society. I dare anyone to find me a successful open source business that operates with nothing more than hobbyists faffing about at home at random. While that’s a fine start, the demands of the real world soon make themselves felt in terms of an increased need for coordination and a more definitive plan and roadmap than the nearest shiny object.

I can but hope that this man is blessed with a king midas touch of shit, and that every startup he ever touches will crash and burn, as it has no choice but to do if anyone involved actually takes his deranged spastic twitching as anything more than a joke that has long lost any humour value. Shame on anyone who takes him seriously.

I’m a fan of java.net. I’m a occasional and regular participant in a number of projects on it. I like the principles behind the service, and always recommend it to people looking for java project hosting.

However, it certainly has its warts. For anyone who has engaged in a back and forth with the poor community managers at Sun, every problem boils to one simple issue. Collabnet are a bunch of spastic moneygrubbing incompetent shirtlifting perlwanks.

Matt Raible for example bemoaned the lack of customization for the navigation, because only the criminally insane and genitally challenged would use the despicable bugzilla or revolting forums that collabnet offers. It’s perfectly sensible to want to customise said links to your own saner issue tracker (yes, even JIRA is a step forward here) or your forums (Jive, another astoundingly greedy bunch of bendoverandpayushaha types, who at least have something worth charging for.)

Another example. Let’s say you’d like a cvs tarball of your repository, so you can run fisheye on it, for the purposes of gawping at pretty graphs that mean nothing. A perfectly legitimate way of pretending to do something useful. Even the turdhaus of sourceforge offers such a service. Collabnet though will only hand over such a thing if you send them enough money to feed an American family of couchpotatos.

It’s surprising, really, that a company such as Sun, with its proud tradition of eating their own dogfood and sticking to java technology, chooses to go with such an ungodly stench of perl and open source jizz splattered all over such a public site. I can understand it if collab at least offered these services in return for publicity, but Sun pays horrific amounts of money to that bunch of spineless slashdot Iwanttofondleericraymond’smoustachewhilebeingfistedbypaulgraham types.

Needless to say, the thing performs terribly too, and in the fine tradition of ever Sun site that has ever existed, thoroughly ignores any amount of rampant clicking on ‘remember me’ type buttons. At least in that case, java.net is merely following a tradition at Sun that has been around for the last 9 years or so, rather than heaping new insults on the hapless users who just want to be able to log in periodically out of sheer boredom.

Of course, there’s no subversion support (too expensive, I bet), and the integration between the various components is as much as one can expect from a bunch of hobbyist tools cobbled together by oily teenagers.

Of course, the real punishment is dished out to those naive or arrogant enough to think that they might want their project documentation available on java.net itself. The time and effort that collabnet has spent to ensure that anyone with such filthy habits is ‘cured’ of them is impressive to say the least. It’s easier to tattoo your bottom with small print documentation and visit ever user interested than actually make anything available on there. At least in the tattoo you do get to make some of the decisions involved in layout and design.

Still, as evil and worthy of mutilation, death, and torture as collabnet might be, Sun does its fair share towards ensuring the user experience is anything but enjoyable. Authorizing projects takes, if you’re lucky, a week or six. Finding a sympathetic community manager to a particular problem is a crapshoot; if you luck out and find one who cares, chances are they’re about to leave Sun, be promoted/demoted to something less/more important, or go on a two month vacation with no email access without notifying anyone.

Remind me to never buy any product that’s a repackaging of existing open sores crap. The people who are always, always trying to pull a fast one and con someone out of some money, and are only ever motivated by being paid to piss around incompetently. I wish collabnet nothing but ill, and hope that everyone involved with them gets what they truly deserve one day. Brian Behlendaft, may you disappear up your own lardass one day.

I spent the weekend working on the TestNG IDEA plugin, and I was struck, time and time again, by how abysmal the so called IDEA ‘open’ API is.

Setting aside what a cruel joke it is referring to the api as anything vaguely ‘open’, it’s astounding, nay, horrifying how difficult it is to work with.

For one thing, there is next to no documentation about it. The fact that the way to write a plugin is to find another one and copy it should be setting off many alarm bells at IDEA HQ. I’m fairly aware of the goings on in idealand, and have yet to hear of a definitive plugin quickstart that’s well known and publicised.

On the plus side, you do get the source (or at least stubs) for big chunks of the openapi package. Needless to say, this is far from comprehensive, and in most cases the sources do not contain any sort of documentation, or are simply existent. There are a ton of classes that are in the openapi package that stubbornly refuse to go anywhere near the source jar.

Figuring out how to accomplish any given thing is an worthy contender for the ‘experience most likely to cause fastest genitalia shrinkage from full arousal’ award. For all the grand ideas that one might have, invariably the implementation is either well hidden away as an IDEA internal, exposed very poorly, or plain old badly written with no thought for reuse.

Classes are often very oddly placed. For example, we have BrowseModuleValueActionListener. This is actually a fairly useful class that allows you to tie a dialog box to the browse button of a textfield. What package would such a class be in? I doubt even the most creative amongst you would choose com.intellij.execution.junit2.configuration

.

Even funnier of course are the typos. The refactoring support means you can consistently have a badly named class without ever noticing. Witness the nonsensical SeachScope

class.

Much of my time was spent wiping off the hot tears of rage and dismay time and time again as I struggled to find out how to get something to happen, or more often, flailed about pathetically trying to figure out why something isn’t happening. Ultimately the only surefire method seemed to be helpless flailing and random clicking until eventually Something Happens. The plugin devkit makes this far less painful than it used to be, but it still doesn’t strike me as the most efficient mode of development; click&pray. I saw enough red circles of doom to last me a few months. I cursed Russians, I wished ill on the lovely city of Prague. Most of all I wished that those guys hadn’t taken vows of stfu about the damn api.

If JetBrains is serious about attacking the eclipse plugin market, then the openapi needs a lot more love. It is currently a neglected abused child only fit for pointing and laughing at, and the occasional bout of sexually deviant behaviour instead of the tender lovemaking that one can imagine exists in this cruel cruel world of ours. It’s a terrible shame given the power than is available and the huge scope for IDE enhancements that don’t belong in the core.

I’ve gotten too many emails requesting this particularly hilarious entity be ‘reviewed’, peer pressure being what it is, I capitulated and decided to have a look at mergere.

Mergere, for those of you with better things to do with your lives than follow every ridiculous idea in javaland, is a new ‘venture’ where some VC type managed to con a bunch of maven developers into thinking they have the makings of a real product you could build a company around.

First, let’s even ignore how ridiculous the idea is, and evaluate this assertion based on the words of their own website. I’m sure that perusing it will make everything clear, and we’ll all think ‘aha! if only I thought of that!’

It’ll come as no surprise to anyone that whoever came up with the site content had nothing further from their mind. The site seems to have been written by a marketoid who once knew someone who had read a java tutorial. It promises us that the maven based solution stack will ‘eliminate most, if not all, human interaction at runtime.’ Now I’m no buildfile expert, but in all these years, I have perhaps come across one or two projects that require any human interaction between issuing the equivalent of ‘make’ or ‘ant’ to kick off the build process and have it spit out binaries of dubious quality.

The solution stack also, apparently, ensures that ‘builds run from start to finish without issues.’ As anyone who might have used maven knows all too painfully, this is about as truthful as claiming that swt is a great cross platform toolkit, or that bill berk is a great public speaker.

What’s even funnier is that these monkeys, like everyone else, are building a continuous integration tool. Perhaps there is a glimmer of hope here, as for some reason this field seems to attract the top tier of java retards; those who seem to have the shortest attention span and least ability. We have anthill (functional, but about as attractive as rod johnson’s moobs), beetlejuice (by Andy wannabethoughtwanker ‘if I rip off the jira look then I will be rich’ Pols, cute yet about as functional as a thoughtworker without a pair), damagecontrol (the only build tool I know of that can without fail bring down any machine it’s installed on, rock on ruby!), and of course, the perpetually dysfunctional cruise control.

On the plus side, the one place you can be sure of to run this pathetic pile of doggypoo is codehaus. Yep, the only people in the world stupid enough to run the most unstable and incompetently written build tool in existence (damagecontrol) will no doubt apply their highly selective acceptance criteria (it compiled, once) to this project, and deploy it.

I do feel some pity for the maven guys. They’re clearly a bunch of happyclappy clueless well intentioned oss hippie types who are being ruthlessly exploited into thinking they’ve achieved oss nirvana. You poor bastards are going to have a rude rude awakening in a year or so once your seed money runs out, and you’re back to whoring yourself on shitty little IT gigs and, no doubt, churning out more shitfests in the hope of ‘making it big.’

Of course, the business plan for anyone who has followed gluecode is blindingly obvious. Throw up enough smoke and mirrors to sell the whole thing off to someone even stupider. While that approach will obviously work with logicblaze (which compete with a number of commercial business friendly tools), I predict an astounding failure for mergere. Not only has nobody ever paid for this sort of thing, but there’s a delicious irony in offering commercial support services for maven too; any build tool that requires you to pay an expert to maintain is clearly badly written and should not be used in the first place. How many companies have made their name and money selling makefiles, or build.xml files?

A lot of the big boys provide shiny pretty tools to ‘help’ you do stuff. It’s rare to find a really expensive server/application that doesn’t give you ‘value-added’ gui’s that help you interact with the complex systems they have built. These gui’s of course ensure that there is a low barrier to entry, that you’re ‘empowering’ your business users, and allowing them to increase their ‘time to market’ and push up their ‘ROI’.

While these tools do provide a good selling point, more often than not they’re in direct conflict with the people expected to work with said system. I’m heartily sick of vendors pimping their latest gizmos with shiny demos and hordes of marketers squealing that ‘people buy with their eyes’. I’d like to stab those people in their eyes with a butter knife. Let’s see them buy ‘with their eyes’ then.

To me, any suite that mandates or ‘strongly recommends’ a gui management tool is basically saying ‘look, our underlying configuration format sucks, it’s convoluted, awkward, and endlessly tedious to work with, if we let you use it, you will either laugh at us or want to murder us in our sleep’. Witness the call for struts consoles, that happened since people started to realize how retarded and obfuscated struts configuration is. Of course, products like JBoss have configuration that is so hopelessly fucked that even a config tool won’t save you there.

While working with a mouse and ineffectually faffing about with options and pictures to accomplish stuff is enjoyable and satisfying to effeminate developers, the manly developers are more likely to feel rage at being made to jump through hoops and treated like an invalid 3 year old. It’s insulting and offensive to be treated this way. Give me a simple set of configuration files that are human readable and editable so that I can stick to using a keyboard like god intended.

GUI Culprits include the horrific weblogic workshop, websphere’s I’m-going-to-chew-off-my-arm-now-to-distract-myself-from-the-pain deployment tools, and my current cross to bear, tibco’s just-stab-me-in-the-face-now-to-end-it-all schema designer tool. Why oh why can’t these tools be advertised as something that is available but very definitely not required? Why can’t there be clear documentation on how to accomplish stuff without these tools, or documents for the underlying mechanisms these tools use so that you can do things your own way if you wanted to? Admittedly, it’s a bit unfair bundling weblogic with the others as the workshop is a latecomer so the config files have had to be coherent and sensible previously, and life can move along reasonabely smoothly without the workshop.

So have your filthy gui tools for your sales force to pimp to gimboid managers, but if you want good will from the trenches, make sure you don’t insult the intelligence of the developers and document all your formats. That way they can use whatever they feel enhances their productivity the most, and thank your app for helping them do it. If you’re REALLY kind and loving, then spend some effort simplifying your configuration, so that the call for a big fancy gui simplify it never arises.

Maybe I’m old, cynical and jaded. Maybe I’m bitterly jealous that I had to cancel my trip to JavaOne at the last minute, or maybe I have very low tolerance for bad writers. The end result of this is that I am finding the coverage of javaone from most (well, all so far) bloggers to be horrifically boring, dull, repetitive, and lacking of any sort of personality.

Maybe that’s not so surprising. Geeks are, after all, geeky types. Bloggers in particular are delighted that they have reason to post without having to actually think. Even worse are those who feel that their blog is a note-taking exercise, there for their personal usage, totally devoid of any awareness of the poor bastard readers who have to wade through that nonsense.

Maybe the initial awe factor is too high, and it takes time for their cute little brains to slowly digest all the material they’ve ingested. Maybe in the coming days, we’ll see more useful observations and more interesting coverage where the observer has actually tried to put actual thought and effort into communicating, instead of the current mindless drone approach.

So what has happened at JavaOne so far? We have about forty bloggers all repeating some variation of the following:

Given how popular appfuse seems to be, I thought I’d give it a try. Now, I personally have no such need of such a tool, but if it actually does what it says on the tin, then it certainly would be worth knowing as something that might be recommended to people wanting a quick start of some sort.

Oh how naive I was! I laughed, I cried, I fumbled about uselessly trying to make it do things. Appfuse is, without a doubt, one astoundingly confused product.

Where shall we start? Well, if you want to do anything other than stick with every single default, you’re up poocreek sans paddles. Let’s start with the installer. It uses izpack (a fine product), but of course, goes for a net install and shows NO INDICATION of progress as big chunks of data are downloaded. Furthermore, if you manage to click on the right combination of things (just my luck), you end up with an installer that’s hung (not in a good way) at 1%, with absolutely no hint of what you should do at this point. Cry like a girl? Wait like a man? Shake your fist at how futile life can be? Still, I tried quitting and examining what it so kindly deposited in the chosen target directory. There’s a build.xml which is about as functional as Geronimo. If you rip it open and peek within, you’ll find it’s actually a buildfile to build the INSTALLER, and could not possibly be more useless to an end user.

Alright, let’s give up on the installer. It was clearly knocked up as a side effect of a drunken stupor. These things happen.

So I go for some other download (binary, getting things to build from such dodgy characters is a bit too wild even for me). Hm, first hurdle, I MUST have tomcat installed. Not only that, but I must also faff about setting environment variables. How user friendly!

Now, I can accept requiring tomcat to be able to deploy the excrement this fine app defecates, but really, MUST the reload task be declared for the whole build file, such that you can’t even do an ant clean without tomcat installed?

Things steadily go from bad to worse. The sloppiness and slipshod I’ve experienced so far is not an accident, it’s a way of life for this app. I try to generate a project, and I’m prompted for my project’s package….twice. Hint to any aspiring UI experts, don’t ask people to type something in twice, it’s rude and pointless and only says ‘I’m retarded and cannot remember what you just told me.’

The project generation phase also kindly informed me that it has autodetected mysql. This was mildly surprising to me, as I do not have mysql installed anywhere on this machine. Maybe it detected something Out There? Maybe it was some kind of sinister warning about the inevitability of mysql taking over the DB world (har har)? Don’t be fooled by the documentation, getting this pile of festering doggie droppings to work with anything other than mysql is far from being a simple switch somewhere.

Of course, the buildfile is what you’d expect from a web monkey pretending to be a programmer. Half the targets don’t work, nor is it particularly clear what they do. I downloaded the webwork version, and ant -projecthelp suggested a ‘install-webwork’ target. This seemed like a promising starting point. Alas, that target doesn’t even apply for the webwork build, it’s for choosing webwork when you haven’t just downloaded the webwork specific version!

Nevermind that, at least the project skeleton it generates is a good robust starting point that one can confidently move forward with.

Haha, only joking, of course. Every object creates builder objects in hashCode and toString. That’s right, every time hashCode is called, an object is constructed and the java gods sacrifice a baby jesus in your name as a result. It’s comforting almost to see such solid proof of how absolutely evil jakarta commons is, when people are encouraged to do this kind of thing.

Even worse, the project’s directory layout is bound to confuse a seasoned webapp veteran, let alone the target audience for this frankenstein of an application. It’s as if someone got very angry and gathered up a bunch of directories, then violently flung them at a filesystem in order to cause maximum distress and pain to the world at large.

Of course, the project uses xdoclet. Now, xdoclet certainly has its uses. Building web.xml is NOT one of these uses. I don’t know what kind of giant supergenius newbies Raibly is expecting, but even I don’t have the heart to tell them than to edit web.xml, they’ll have to find the appropriate fragment of it (out of 11) and slot in the right thing, then rebuild to get the aggregate descriptor generated.

Of course, the forums and users of this application are the icing on the cake. Poor perplexed lost souls, endlessly befuddled by how and why things are the way they are. Those who do stick with it invariably realise what a completely spastic idea it was to start with such a rotten festering foundation.

Matt Raible once blogged that he’s perplexed by his popularity and the world viewing him as some kind of expert. Little did I know how right he was then. He is, as he proclaimed, a depressingly average web monkey who was catapulted into the limelight through a freak accident of nature. Of the other hand, maybe their little hearts are set on him, their minds filled with possibilities as they wisely ponder ‘If this idiot can do it, so can I!’

PS Yes, I have google ads now. About time I get some money off you losers.

So our Apache heros have now decided that it isn’t quite enough to prove to the world that they are abysmal failures at producing a J2EE container, they must now further prove their incompetence by attempting to produce a J2SE implementation too.

Where does one begin? These guys have not only lost the plot, they’ve also moved on to a different plane of reality altogether. It’s astounding to me the free time that these wankstains have. They are the pinnacle of open source, the ultimate proof that in a system where nothing is driven by economic, practical, or realistic goals, in an environment where time is always worthless, every fool and his genitalia will waggle every which way, simply because it’s physically possible to do so.

There’s something very revolting about polluting a clearly technical and practical field with so much religion and dogma. The apache incubator proposal for this travesty is a perfect illustration of the role of religion and faith in this obscene idea, stating that there is a ‘clear need’ for an open-source version of Java. Is there? Who is this clear to? Certainly no java developers who have been polled multiple times in a variety of venues. The open source spastics are always a loud and obnoxious minority. Perhaps Apache has been suckling a tad too zealously at the slashdot teat of knowledge.

Even funnier is the approach they’ll likely take, which is the exact same one that has made Geronimo the raging success it is today. Smear together separate yet distinctive piles of animal excrement in the hope that by mashing this all together, something tasty and useful will be produced. There’s a REASON that openEJB had all of 3 users for all these years you know.

I could at least partially understand the driver for Geronimo, since it was basically a bunch of greedy jboss rejects that wanted more recognition, a human weakness that we can all understand. In this case though, who are they trying to spite? Or will the ace up the sleeve be that IBM can use this to perpetuate the concept of Apache as their karma whore and universal dumping ground and ‘donate’ more of their pathetic attempts at producing useful code?

Even the JBoss guys are more coherent and easier to relate to than these loons. One can understand people being driven by greed and egomania. You can argue rationally with such people, even if you feel disdain and dislike for them. There’s something human and accessible there (to varying degrees). With the apache people, there’s a disturbing gleam in the eye that forces you to slowly back away. They’re zealots with that rabid frothing and insane cackle indicative of their willingness to die for their religion. No amount of rational debate can filter through. Even the merest attempt will result in drooling, furious hand waving, and brandishing of moral codes of conduct.

So for this obscene J2SE idea, we have another set of real winners being assembled. Who can deny the usefulness of kaffe! They even have partial support for JDK 1.1 AWT by now I’m sure! How about the performance benefits of Classpath? THEY even have a preliminary swing implementation! You can’t go wrong by integrating in ‘mindshare’ from GPL projects that were created purely out of religious beliefs instead of any practical needs eh, it’s a winning recipe for sure. The hilarity of attempting to lend legitimacy to this foolish idea by putting the names of the developers of those pathetic futile attempts on the list shows a mind firmly embedded in lalaland.

How can this not be blatantly obvious to everyone? Projects like kaffe and classpath are worse than worthless. Even the notoriously dimwitted java community knows better than to use such tripe, and these are the people who gleefully add commons-logging (clogging) to their projects while sporting that revolting shit-eating grin that’s all too familiar. These are the people who will swear up and down that jboss and tomcat are good projects that perform well. If even these people scorn the ideological bullshit that results in the genesis of crap like GPL implementations, why don’t they just die the quick miserable death they’ve so richly earnt?

On the plus side, we have a delightful architecture diagram for this new J2SE implementation! It shows all the layers in a cute boxy diagram. Hardware at the bottom, class library at the top. Gosh, no wonder they’re so optimistic, all the hard work has already been done! There’s a picture there that explains it all! If only Sun had access to such architectural geniuses, we might have a functional JVM by now. It’s breathtaking, it truly is. These people want to build a JVM and they have NOTHING. All they have is a crayon drawing, boundless faith, naive belief, and the cheerfulness of a village idiot. Their approach will basically to sit with thumbs firmly in anuses hoping for droppings from IBM, BEA, Sun, nd anyone else who needs to go whoring for some good PR without actually doing anything meaningful or useful to the population at large. The list of participants is there to add insult to injury in a way, a collection of misfits half of whom are some combination of incompetent, brain damaged, fanatic or quite simply clueless.

It’s astounding that while the outside world proves to us again and again that separation of church and state is a good thing, and is a winning recipe in terms of stability, growth, and fairness, we in the java community seem hellbent on marching in the opposite direction. No longer will market forces or the common good based on rational clear arguments be the guiding hand for our future. Instead a group of rabid religious degenerates with too much time on their hand and too much power and influence decide that open source must be preached everywhere and everyday. Damned be Apache, and damned be the the legions of filthy masses who do nothing more than clap idiotically like trained seals at the world around them. Your Pavlovian reactions are a disgrace to humanity.

As the latest EAP of IDEA nears completion (or more accurately, stumbles forward towards a ship date by carefully avoiding any semblance of completion) it’s time to dissect this latest release and issue forth my bi-annual IwanttostabIDEAloudmouthssinthegenitalswithahotpoker diatribe.

In many ways, this release continues the fine tradition established in the 3.0 EAP. An amusing, yet depressing attempt at cramming in features for users who have long since lost any form of plot they might have had some weak grasp of in yesteryears.

So where do we start? Well, xml editing is always a fun one. It doesn’t work. For some reason (despite being reassured by everyone that this IS supposed to work), my schema declaring descriptors wash their hands of their schemas, proclaiming themselves independent with astounding quantities of red liberally applied.

Of course, when xml editing does work, which does happen purely due to the laws of statistics, it’ll invariably be slow and painful, with the odd element always trying to make a name for itself by indenting itself in a manner than is entirely at odds with everything else.

Needless to say, this joy extends to ant files. Custom tasks have as much chance of being detected as James Strachan has of writing intelligible documentation.

Of course, if you thought xml editing was were all the fun and games are, then you should try editing jsp files, which is more or less guaranteed to have you rummaging about for the nearest pair of genitalia to gnaw off in sheer desperation. JSP editing in fact is so astoundingly broken, so thoroughly useless, that I have had to resort to mapping the jsp extention to be a plain text file. Every character you type will bring about the Circle of Doom (the annoying little red harbinger of badthings in the status bar that says something horrible has just happened). The fact that the CoD is a burning red distraction is insufficient, nono, we must also have a goddam popup with an ARROW pointing at it telling you that you have just met your doom. Wound, meet the fistful of salt you’ve been so eagerly anticipating.

Still, at least the java editing works, eh? Nope! Creating a pair of new braces with code inside them will invariably poo all over the indenting of the line following the last brace. Typing characters in a large (few thousand line) java source file is a leisurely activity where you can quite reasonably expect to call up some friends for a good old fashioned circlejerk, wait for them to show up, and indulge in a marathon session with said friends while waiting for the IDE to admit you’ve actually typed something.

The open API is, of course, yet to be blessed with a single line of javadoc. To be fair, it does make life more exciting; always trying to figure out what a particular piece of code will do. Which does bring about one of the surprisingly few useful features of the latest EAP; that you can very easily create a sandbox to run your plugins in with little to no effort.

To be fair, there are many small improvements here and there that improve the usability overall. The concept of javascript/css/html refactoring and a language aware editor is new and exciting, if the IDEA guys manage to pull it off. The level of language knowledge built into the editor far exceeds anything that exists currently (eclipse users, please go away quietly you worthless cheapskate turdburglars). Whether they can pull it off though and manage a usable release is another matter entirely.

I remain, as ever, a devoted and passionate IDEA user. The loathing I feel for the loud EAP users (gimme subversion or I will cry and soil my pants!) grows apace. I can barely stand to post on the EAP forums these days, such is my disgust and rage. This is, however, one of those rare cases where the rage is a manifestation of love and care. I can only hope (in vain, if history has anything to say about it) that the fine fine developers of this beautiful product rethink their approach and get back to thinking of their product as being exactly what they’d love to use, rather than what they think others would enjoy using.

It looks like the Java6 (or rather, Java SE 6 as the marketing gods will insist from now on) people have finally joined the moron parade that is the rest of the java community.

The particular idiocy that has resulted in wise men everywhere losing bowel control is the embedded javascript engine.

Why, in the name of all that is pink and fluffy in this world, does java need this? How many times have you bastards thought ‘god, I’d use java, if only it had a javascript engine that didn’t require that I download a jar’?

What’s even more incredible that this spastic idea is the reception it’s received. I’ve always been bitter about how retarded most java bloggers are, but the number of people who have happily drooled onto the ether about what a great idea this is (without ever, ever presenting a coherent or intelligible reason as to why) is flabbergasting. The idiocy of the masses is one thing, but to have so many individuals spontaneously display their genitalia all aquiver over such a pointless exercise is inexplicable, to put it mildly.

Even more astounding is the fact that the html engine in the JDK still can’t render anything more advanced than HTML 3, yet we have a bunch of filthy unemployed drama queens cooing about how great and important javascript support is.

The scripting host engine I can somewhat tolerate. After all, the scripting crowd is loud and obnoxious and easily appeased, so might as well toss them a bone (or two) to insert into the odd orifice (or two) to pacify them. No doubt, in typical JDK team manner, they’ll still work hard to mangle it up and not bother talking to anyone about how classloading actually works and demand all sorts of command line switches and sacrificing of children to the classloader pantheon.

The idiocy of course doesn’t stop there. We now have a ‘lightweight’ embedded http server. I suppose SE 7 will include tomcat eh? Maybe merge EE and SE, while we’re at it! Who needs something you can download in mere hours, when you can wait days for the joy of something you never even asked for in the first place!

If anyone is bored and out for a seriously hilarious read, try browsing the harmony-devel mailing list. If anyone has ever suspected that this project was formed by a bunch of clueless asshats, then it’s time to lay those doubts to rest and confirm the cruel harsh reality.

Of course, I realise that whenever any such massive project kicks off, the usual quota of lemmings will hurl themselves at it, promising the world and then getting bored within a couple of days as they realise that enthusiasm, good will, and desperation do not produce much code by themselves.

However, reading the list kept reminding me time and time again of another collection of mailing lists that had very similar content. For those of you old enough to remember, this is exactly what all the mozilla mailing lists sounded like back in 1998 or so. Everyone applauded the project for being an absolute stroke of genius. Everyone wanted to contribute and stick their oar in. It took about five years of wasted time and effort before even the most retarded of retards decided it’s time to give up the ghost, and salvage what can be salvaged and start from scratch (again).

Of course, the difference in this case is that the apache people have shown us time and time again that giving up is not an option. No matter how stupid an idea they have, no matter how much hatred they generate, no matter how many people will despise them, there’s always a v2 around the corner to alienate a whole new set of people (yes, that’s your obligatory maven reference). Why oh why can’t these people’s day-job managers keep them too busy to keep harming the rest of us?

So what does this hilarious mailing list contain? Well, here are some highlights:

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.

It’s really astounding how easy it is to pull the wool over the java kids’ eyes and amuse them for hours on end by merely dangling a shiny object in front of them.

The latest example of this is the one of the ‘ajax’ poster boys, json-rpc-java.

I am truly baffled that people take this crap seriously. At best, it’s a cute toy with a couple of neat tricks that one could copy. At worst, it’s a evil evil implementation that’ll bite you in the ass if you ever expect more than 3 users or would ever like to cluster, use declarative security, fine grained access, method level anything in fact.

The idea itself is not that bad. The implementation however is almost like some kind of sick sick joke. For those who have so far been wise enough to avoid this shiny bauble, it’s basically a clever hack built around xmlhttprequest and some javascript to java serialization that allows you to invoke arbitrarily methods on serverside java objects.

So how is this done? For reasons best known to to the authors themselves (and no doubt applauded by the shit-eating-grin sporting ajax crowd), they basically bung everything into a session. Now, you might be forgiven into thinking that ‘everything’ here is just lightweight stateless information. You’d be so so depressingly wrong. Every means that each user gets their own JSONRPCBridge. This class is so incredibly session-unfriendly that it doesn’t even implement Serializable. Even if it did, mind you, you’d be even further up shit creek sans paddle. Said class contains every exposed object, every exposed method, and every exposed class. Persisting this to anything other than memory is likely to take a few days at best, while your hapless user is left sitting there with any number of thumbs inserted into any number of orifices. Adding to the general hilarity within this class, we also have a static classCache map. It’s the gift that keeps on giving!

Of course, should you to refuse to use said session object, you’re forced to use the ‘global’ bridge. Of course, when asshats like these say global, you just know they mean ‘static’. Of course, of all classes they could have possibly stuck the static, which did they pick? Yep, you guessed it, the very object they’re shoving in the session!

The documentation of course is in the fine tradition of open sores. It starts off well enough, but halfway through the manual, the author simply lost interest in the whole thing and just gave up, leaving 4 sections totally blank. Just imagine the hue and cry if a commercial vendor dared have empty swathes in their documentation. Why on earth is such incompetence tolerated and nudgenudgewinkwink-ed away in the opensores world?

It’s quite a shame really, the project is a cute little gizmo, and to the authors’ credit, it has no dependencies and does not use maven, so they’re not completely braindamaged. They do try and go out of their way to make up for that foresight though by forcing their hapless victims to edit build.xml and specify twatty tomcat values. It is truly astounding how few people seem to know how to use ant, or how others expect to use it. The developers’ real downfall however seems to be that they were never beaten with the scalability mallet as children. So if you kids know what’s best for you, let the beatings commence!

Ahh, that delightful apache/IBM relationship. So much has come of that unholy alliance. If there’s one company that has done its utmost to inflict as much crap java on us as can be imagined, it is IBM. I mean, forget the big stuff like Websphere, all the incompetent, inefficient and over-architected classes in the JDK, or their craptastic JVM’s. Let’s look at their latest ‘donation’ to the apache imbeciles, Derby.

Derby is the result of IBM deciding that Cloudscape is a joke that nobody sane will ever pay for. The only company stupid enough in fact to touch the unholy mess is, surprise surprise, Sun. Even that was a leftover from the good old days when they believed that everything written in java was pure genius.

So, one might be forgiven for wanting to actually use the database. After all, it’s pure java, setup can’t be that hard. Just look at mckoi or hsql, quick download, and you’re up and running in under 60 seconds.

Unfortunately, you’re in for a very very rude shock if that were your assumption. It’s easy to forget exactly how incompetent the apache people are. It’s easy to misremember their King Midas touch of shit when it comes to the written word. How fucking hard can it be to write documentation, I ask you? One of Apache’s prime requirements for their page authors seems to be an English test. Anyone who passes or is able to communicate any idea succinctly is immediately failed. It’s like they found someone to rustle up some derby docs. The guy was bright, he knew his way around the product, and was eager to work. So the Apache powers that be proceeded to ‘apachize’ him by jamming forks in his colon, pulling off his fingernails, and dropping him repeatedly on the head. Only at that point is he deemed fit enough to write docs for that illustrious den of evil. Documentation that is finally guaranteed to be the correct level of obfuscation, obscurity, and user unfriendliness.

Let’s look at some concrete examples. The first step is, of course, to read the getting started guide. This guide goes out of its way to force you to read other documents to actually…get started. If you wanted to run the server in anything but embedded mode, you’re told to fuck off to some other doc. If you click on ‘libraries and class path’, you’re told to go read some appendix. The getting started guide in fact is remarkable in how it manages to contain so many pages without ever telling on how you could actually get started.

Of course, you HAVE to read the guide(s), since in true IBM/Apache style, they still refuse to write a manifest with Main-Class in it. It’s almost a if there’s a feud going on between the manifest haves and havenots. The havenots at this point have just invested too many years in their current approach, and feel they must stick to it out of a sick sense of honour or risk losing face.

Of course, all the documentation has that distinctive apache stench. It’s built with forrest, tool of gimps, sexual deviants, and child molesters. Each page contains a convenient link to itself, in case…errr…you ever get lost. Half the suggestions to read some other document involve helpless flailing and clicking about to find said document. The left nav is the most amateurish attempt at a javascript tree menu since 1996. Thank fuck I can play with the font size though, joy of fucking joys.

Eventually, after a few minutes of this pointless browsing, you will give up and resort to using google. On doing so, you will find that it is, in fact, impossible to connect to this great database without downloading a driver from IBM.

So off you go, to IBM, to download said driver. More clickflailing about. IBM’s website is truly a horror amongst horrors. It makes Microsoft’s site look like a usability wet dream. Eventually, you’ll arrive at the download you want, and of course, be told you need to register.

Unsurprisingly, registration involves revealing your sexual preferences, stance on abortion, and the last time you jammed anything in an ‘outy’ orifice. Still, you’re giving over this information for a good cause. The promised driver will arrive, the db will suddenly become usable, the idiotic cloudscape script you’ve been sent will go in cleanly, and all will be well.

Hah, right. How foolish could I possibly be? Given all that had happened, how could it be this easy? After all that mad clicking, I am now registered, and the next page is step 3 of 3 in the download. It is on this page that I am so cruelly informed ‘This product is subject to strict US export control laws. Prior to providing access, we must validate whether you are eligible to receive it under an available US export authorization. Your request is being reviewed

‘.

Joy. What are the chances of my request being reviewed at 1:30am on Thursday night, I wonder? I mean, IBM employees are like government workers; they’re snoozing by 2pm, and if anyone is in the office at 4:30, it’s a modern day miracle.

It’s hard to express the rage and hatred that I feel towards these two organisations. Never have so few committed such brazen acts of incompetence and gotten away with it so readily. The mere existence and success of Apache is a testament to the fact that the world cares nothing for competence, innovation, labours of love, or quality. The lazy, incompetent, petty minded, short sighted masses recognise one of their own, and they are flocking like the filthy little sheep they are.

Why oh why oh why must so many projects work so hard at alienating so many users? What is it about open sores that, more often than not, behaves as if it’s some plague ridden leper that does its utmost to convince you to walk far far away as quickly as possible?

I’ve ranted about this before, but running into it day after day still gets my blood boiling. What the poo is the obsession with shit like a build.properties.sample file? How hard can it possibly be to create a build.xml that does NOT require tweaking or customising?

For fuck’s sake, even maven, a tool for spastics, by spastics, a tool that’s so badly written it would make any number of holy figures break down and cry like little girls, a tool so horrifically incompetent that it’d make the baby jeebus attempt to gnaw off his own family jewels, manages to actually get this right.

Of course, unsurprisingly, the biggest culprit here is jakarta projects. That grand repository that is almost satirical in nature. The consummate ease with which it demonstrates all sorts of ‘this is the kind of code that the average moron develops, welcome to the real world’ principles is truly a work of art.

It’s not even worth enumerating all the projects in jakarta that do this, the ones that don’t are few and far between. Lucene is a worthy exception; how those lucene devs sleep at night while being part of such an embarrassingly incompetent organisation is fast becoming a modern day mystery of epic proportions.

Of course, when you’re used to this level of pain, having to cp build.properties.sample build.properties and maybe add in a path to your favourite servlet.jar might seem trivial. Projects like slide and taglibs however go out of their way to make the experience unique and memorable.

It is insufficient in this case for example to merely specify that. You will often have to also specify an xml parser implementation (sometimes even separate sax and dom jars!), the path to jaxp.jar, maybe a jmx jar, the clogging jar, xalan, and often paths to multiple versions of said API’s.

In some rare cases (never, in the case of jakarta projects), there is actually a legitimate reason for not including some of these jars for legal reasons. In this case, ant’s <get> task will do nicely. Even if it fails, it wouldn’t kill you, asshole rumpranging chozgobbling shirtlifting developer, to avail yourself of the delightful <available> task in ant to check for your idiot jars and maybe, just maybe, provide some kind of useful feedback as to what shapes the poor overworked potential user needs to contort into in order to get your worthless sorry project building.

So please, please, stop hurting us poor users. There’s enough other stuff that defecates on us from great enough heights that this last touch seems just a bit excessive.

Anyone subscribed to the groovy mailing list must either feel exceptionally gleeful, or horribly depressing. I won’t rub too much salt in the wounds of the latter group by cackling about being in the former group. Oh wait, I will, because they’re a bunch of spastic hobbyist fuckwits would should all be fired.

It is with particular glee that I note that no serious work is now being done on groovy. Even the morons who decided to commit to it are starting to complain. Bugs are piling up, the developers have mostly moved onto the next shiny bauble, and there are calls for fresh blood and a ‘new’ set of developers to get things going; a fairly compelling symptom of a project in its death throes.

Particularly hilarious is how all the turdburglars involved feel that getting together for some drinks constitutes a move forward. It’s really quite amazing that any of these people have actual jobs. Is that how you do things at work? Go out for a drink and your projects just magically finish themselves? Perhaps you blog about it a bit and tell everyone how great it is, and then documents magically write themselves? Or perhaps you’re one of these new breed of fuckstains, who think that the code is the documentation and brag of that, instead of the traditional shame usually associated with making such a comment. On the other hand, groovy could be breaking (more) new ground by being the first JSR where the final spec format is…mp3 (for those of you not reading the lists for their comical value, the ‘outcome’ of the groovy JSR gettogether is nothing but a bunch of mp3′s).

Still, at least it’s good to see that after all these months, the end of line semicolon saga is still dragging on, as are all of the syntactic sugar issues that people raised all those months ago. Democracy at its finest.

It almost seems spiteful in fact, how the groovy fearless leader seems to go out of his way to never post anything to the mailing lists.

It’s also delightfully satisfying to see that the early adopters are being punished, as they should be, by guarantees that the syntax will change in non-backward compatible ways. You fuckers need to be clubbed on the head like that so one day, one day, you might actually learn.

As if that wasn’t enough, there’s also a regular posting of the build breaking or someone unable to get it going, thanks to the wonderful magic of maven. It’s truly astounding what sort of shit people will put up with in order to uphold their religious convictions.

The one person who has to be pitied though is poor Guillaume Laforge, who is the only remaining groovy developer. He tirelessly responds to emails on the mailing lists even though he probably knows deep down inside that it’s a lost cause. It’s sad and depressing, but I suppose some people just don’t know when to give up. if I were his employer though I suspect I’d gradually start getting more and more annoyed at my employee pouring so much time and effort into such a dirty toilet.

I have to give credit to Sun as well, for managing to milk so much good PR out of pretending to listen to these monkeys. First they accept the JSR, knowing how unlikely that a bunch of open source ADD kids can manage to stay focussed for a few minutes, let alone the months a JSR requires. It costs them nothing, and all the usual suspects will be dazzled and impressed.

Even funnier is Tim Bray’s PR stunt to get that group of misfits together. They came, they saw, they chatted and looked serious, and in the end, of course, very little will actually happen. This is all a great thing, people doing real work won’t have to worry about the children smearing feces all over themselves, and the children get to smear feces like they’ve never smeared before.

Will groovy ever get past the alpha stage? Sure, it’s quit plausible. It’s quite a race between them and the JDOM JSR. What is clear though is that if it ever makes it to a final JSR, you can be sure that the current developers sole contribution to it would be as a footnote in the credits section. In the meantime, I’m going to sit back and gloat and scream out I told you so to anyone who’d care to listen.

It’s fairly impressive how unit testing seems to have grabbed a number of java developers by the balls, and made them sing in surprisingly high voices.

Of course, we all know the virtues of unit testing. It’s great, it lets you err…test your little unit of code. It lets you pretend you don’t need any QA engineers, and rewards you with nice green bars (or ascii dots, if you’re into that sort of thing) that seem to have a disturbing sexual appeal to far too many people.

What is surprising though is the religious aspect of it. For example, some comment on a blog a few weeks back had someone spouting shite like ‘well I’m not a zealot or anything, but I would never use code with no unit tests, it works by accident not design’. What’s particularly sickening about this is the fuckfaced disclaimer up front. It puts the whole thing right up there with such gems as ‘Well I’m no racist but those niggers…’ and ‘I’m no bible thumper but YOUR ALL BURNING IN HELL YOU GODDAM ABORTION LOVING BABYKILLERS’ (Note: The typo is deliberate).

Surprisingly, the developer world hobbled along quite successfully before junit. Huge portions of it keep on hobbling that way with astounding success. See, what people seem to have forgotten is that a unit test does not mandate junit. It’s the approach that matters. Coverage reports are there to make things more sexually stimulating, they’re NOT a fundamental part of the approach. You could have plenty of unit tests that are nothing more that main methods in your various implementation classes. That still has its value, and certainly is more useful than no tests at all.

The JUnit fetishists are the freakiest of them all. What’s impressive is that they’ve invented this whole new universe just to justify what a horrifically broken tool they’ve staked their careers on (yes thoughtworks fuckstains, I’m pointing and laughing at you, you dirty chozgobbling rumprangers). Need static initialisation for shared or expensive resources? Not possible in Junit! Therefore, it’s evil! if you need to do it you’re broken!

The same goes for anyone who ever expresses any need for something beyond one method one test. Why the religious zealotry here? We all write code every day that requires more than one method, so why can’t our tests function similarly? Why is it so unthinkable that there might be some element of good unit testing that are not fully captured by JUnit?

The sickest joke in all this is how badly JUnit itself is written. Just read some of the javadocs and inline comments, they make it fairly clear that a fairly liberal amount of drugs had been imbibed in the course of writing it all.

So I ask you, all of you who want nothing more in life than to bend over and have JUnit plug all your orifices, why? What do you get out of it? Why this sickening allegiance to a flawed, old, unmaintained, and dysfunctional tool?

Update

: In my fury at junit, I forgot to mention my shameless plug. If you’re a JCP member, vote for me in the EC elections! If you aren’t, join then vote for me. I’m the only nominee who is motivated purely by improving Java. Everyone else is there out of some business need or corporate agenda. Stick it to the man!

Ahh, the wonders of hindsight! Remember yesteryear, when things were fresh and new, and the sweet sweet stench of innovation hung heavy in the air? Such promise, such hope! So many little API’s poking their shy little heads out of various birthing orifices. So many developers running around like cute little headless chickens hoping for a pat or nod of approval from an ignorant, shiteating-grin-wearing crowd.

Well, let’s catch up with some of those happy events and persons, and see what they’re up to now…

The first stop on this sordid little tour of the past sees us visiting the hapless Jon Tirsen. Once a promising young developer of dubious Swedish/Norwegian origins, he quickly found a home that could put up with his severe Attention Deficit Disorder (ADD) at ThoughtWorks. Remember when he cooed and oohed and aahed and excreted happy juices rubywards? Remember when he managed to get onto the frontpage of TSS with his ruby continuous integration tool, DamageControl? Well, the poor kid’s ADD was so severe that even his employer thought it’s best if he’s just put away from harm’s way, and promptly shipped him to the penal colony down under, while defanging him by putting him to work on such menial tasks as build tools.

As for DamageControl, the only user is codehaus. In fact, it’s such a pathetic failure of a tool than even the incredibly undiscerning eye of the codehaus folks is becoming more and more annoyed at this tool that manages to fall over more often than crazybob in Vegas.

No pointing and laughing at Tirsen is complete without some measure of pointing and laughing at his cohort/sidekick/puppetmaster Aslak Hellesoy.

Poor Aslak’s only legitimate claim to fame is STILL only xdoclet. After stalling horribly on xdoclet 2, he went on to join ThoughtWorks and underachieve in a surprising number of projects. First we had picocontainer (remember THAT?!), then DamageControl, and finally a series of hilarious TDD tools in a sad and desperate last bid attempt for some kind of recognition. It’s so sad seeing great men fall so low, but a key part of playing this game is knowing when to quit. If you’re now writing silly TDD toys that delete code (and don’t actually work) then you’re well well past that point of quitting with dignity.

Of course, this being Java, we should visit some tools as well as persons of dubious character. The first stop is in fact somewhat of a happy note!

It turns out that after a year of whimpery sad death throes, Jakarta Avalon has finally given up the ghost. It’s so nice to see projects dying, a sign that out there in the great developer wilderness, a few lone voices of discontent and misery can in fact push through and get something (un)done.

Next up we have Maven. Remember when people were excited about it and thought it was some kind of competition to ant? Remember when people used to actually defend it? Well, the current state of play is that even jakarta hardcores are complaining and bitching about it. Maven 1 devs now flail about hopelessly on their silly plugins, while some make half-assed attempts in maven 2′s general direction. I’m sure The ADD crowd with piddly toy projects will soon move to this new version, and no doubt then join the huge mass of mavenmockers out there.

Finally, groovy! Remember when people thought it was cool? Remember when some smart people said they’d turn it into a proper spec? Well, those days are long gone. One of the few smart people involved in that ungodly tripe, Sam Pullara, has moved onto bigger and better things. James Strachan of course is still cursed with the attention span of a gnat, and is now busy churning out Active projects through some new cockamamy moneymaking scheme. The JSR has not moved one little bit beyond forming an expert group. What an expert group too! Note the lack of a single language expert. I can’t think of a single JSR blessed with such a high hobbyist to expert ratio; A dubious honour at best.

So, what other spectacular failures have there been? Any news of other misfit hasbeens that should be made public and some more humiliation poured on their already quite miserable existence?

What is it with open sores projects and usability? I am baffled by all the energy and effort expended by any open sores project with a UI to avoid usability and principles of good design at all costs.

Maybe it’s a subconscious effort to emulate linux. Just as children will adopt the bad habits of their parents, java open source fuckwits will emulate the linux approach to UI; a disgusting soup of every possible ingredient ever conceived by man or nature coupled with a sickening obsession with every ugly default possible.

Today’s vomit lands on a tool that seems to be gaining some popularity; FindBugs.

In addition to the open source curse, FindBugs is unfortunate enough to have been conceived as an academic project. Those facts combined have meant the kiss of death for this poor little app.

Where does one start? Well, lets first create a project. Here’s the first mystery. You have 3 areas, one of which contains ‘archives or directories’, the second of which contains source directories, and the third is for classpath. Now, I’ve only been doing java for about 8 years, so I might not be familiar with all the lingo, but how on earth is a ‘archive or directory’ different from ‘classpath’? Of course, there are no hints or tooltips as to what should go in these areas.

If you haven’t yet deleted this miserable little app and fired off an angry email to its hapless developers by now, you’ll notice the second bit of mindless cruelty they’ve chosen to inflict on the poor sap attempting to use it. While the file chooser allows for multiple files to be selected, the app itself will merrily ignore these and simply pick the last one you chose. I suppose that’s one way to discourage people from having lots of dependencies.

If by some freak accident of nature you’ve managed to last this long, it’s ready to finally ‘find bugs’. Here we have more unwelcome anal intrusions in the form of a modal progress dialog. The progress dialog will happily write things to the UI console, except that because it’s modal, you have no way of actually looking at all the things it’s whining about. Of course, the warnings are deliciously verbose too, with every line beginning with a full timestamp and the fully qualified class name of the internal handler that reported the issue. I am utterly baffled by this classname fetish that opensores projects have. What exactly do you people get from showing your classnames to your end users? Is it some kind of freakish penis waggling maneuver? A bizarre mating ritual? Emotional issues resulting from being beaten and molested as a child?

Of course, the modal progress dialog has a cancel button, and if you press it you get….another modal dialog, asking you to confirm. Now I’m no grizzled UI veteran, but in all my years of using computers, I have yet to find an OS with such a bizarre paradigm. Real innovation here guys, a modal dialog with one button, that confirms with another modal dialog when you press said button.

The default settings are also of highly dubious quality. Every time you return a Date field for example will cause findbugs to throw a hissy fit. Ignoring results from reading streams (something which is often perfectly legitimate) is also whineworthy.

Of course, should you wish to change these detectors, your eyes will be stabbed yet again with this unfathomable UI. You’re presented with a JTable where the detector fully qualified class names are listed, along with ‘speed’ and ‘enabled’ columns. Of course, since it’s open source, nobody knows how to actually use a JTable, so the columns are all the exact same size. This results in every single class name being truncated, for your maximum viewing pleasure.

The problem is, the application’s functionality really isn’t that bad. The presentation and user interaction though is so astoundingly horrific that the only people who will ever take this seriously are the kind of tosspots who wouldn’t know elegance and clean design (whether it’s in UI or code) no matter how many times they’re clubbed on the head with it.

The one solace I have from all this is that it has nothing whatsoever to do with JSF, so hopefully Rick Hightower will stop working quite so hard at earning the coveted ‘most tedious windbag’ village idiot subcategory award.