The BileBlog

1 - Always provide shell launchers for ant. A standalone build.xml is simply too demanding for developers, who are used to luxuries like build.bat and build.sh. Nothing says ‘we care about your platform’ like shell script launchers.

2 - While you’re writing those launchers, make sure you provide specialized ones so users can very easy call various build targets. Build.sh looks naked and sad without its childhood friends, make.sh, compile.sh, docs.sh, and run.sh.

3 - Never place your build.xml file in your top level directory. The deeper in it is, the more likely it is that people will actually look at your stuff in a hopeless effort to find said file.

4 - Never allow for people to customize the build process. Sourcing an external properties file is just cause for confusion and trauma.

5 - If you do want customization, then force users to define env vars. Since every user’s environment is unique and specific, why not demand and expect them to define 12 *_HOME type variables first? That way when they do get the build going, they’ll feel it’s like a personal customized version that is tailored for their own needs and nobody else’s.

6 - Never rely on -projecthelp. The default ant target should do nothing but spit out a few pages of useless info explaining all the available targets. Yes, ant does allow for this via the -projecthelp switch, but that assumes users know when they need help. It is obvious to you, almighty developer, that unless they explicitly ask for something else, they want help.

7 - Your default target should try to surprise and amuse users. Why have a target that just builds your project when instead you can have it build a whole distribution? Sure, builders are those who might well poke about the source and want quick builds via ant, but screw them. A whole distribution just looks so much more professional.

8 - Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where.

9 - Never ship dependent jars. As any true maven asshat knows, jars should be delivered over the network from a central repository. This way you can automatically weed out those pesky enterprise users behind restrictive firewalls who are in all likelihood violently opposed to opensores anyway. Make liberal use of the get task, it’s there for a reason you know.

10 - Ensure a fresh start! Every target should depend on the clean target. This way you can be sure that the user will not have any problems with left over cruft from an old build. Sure, their build rate will slow down by a few orders of magnitude, but it’s better to be safe than sorry.

11 - build.xml should be your gateway to everything. Don’t be fooled by its name, you can and should use it to run your apps too. Why bother with pesky manifests and cumbersome jar files? They’re from the evil un-free empire of Sun, so you must shun them. Instead, make liberal use of the java task in ant. Real build.xml love will shine through the next time you type ant run.

12 - Consolidation is for the weak. A single buildfile basically screams out ‘I’m a girl and like bunnies and wear pink fluffy dresses’. If you’re going for a more manly effect, then split your build.xml files into as many pieces as possible. Extra points for bragging about reusability and employing cunning task obfuscation. The casual user must never be able to figure out what is actually going on, or they’ll get funny ideas that they could have done it themselves.

For a while now, I’ve tried very hard now not to blow up publicly about the pitiful state of opensymphony. Previously I’ve resisted from whining too much because, well, it’d be a bit like spitting in your own eye. Not to mention that in this particular case, it felt a bit too obnoxious (even for me) to whine and complain about something that is directly in my power to fix.

No more though! I feel much better about whining now because the stupid system that is in place actually makes it impossible for me to fix things, even though I’ve tried. For one thing, there is absolutely no direction or ‘leadership’ of any sort whatsoever. Joe Walnes had lost interest a couple of years ago, and any new projects he comes up with will be housed almost anywhere but in OS. Mike of Atlassian now has a shiny company to pour all his efforts into, so OS is only useful to him insofar as it benefits his company. Any open source urges he might feel will happen under the Atlassian banner as it’s good marketing (Seraph, for example). The most work I’ve seen him do for OS is converting the website to a broken-halfcompleted state to a pastel atlassian look (note the beta message that’s been at the top for a few months now). Sorry Mike, you’re a great guy, but lets be honest here, your performance for the last 18 months with regards to opensymphony has been pitiful at best, at least from my (maybe ignorant/uninformed) perspective.

To be fair, Pat Lightbody at least has some genuine interest in opensymphony (an interest that is offset with a busy real job and no actual dependencies on opensymphony for anything). My constant nagging at him has had a 25% success rate, so it’s just a matter of sticking at it and nagging as often as possible.

What finally drove me over the edge was that damn website. I’ve wanted things updated on it for months now, and nothing ever happens. I’m not updating content to make myself look good, or to try and generate more business for my company, or for cosmetic reasons. It’s simple stuff like making sure javadocs are current, and links are accurate and so on. I’ve asked for the jira installation to be updated, but I guess there’s no reason for that to happen since we’re a charity case and not a paying customer. The website, wiki, and jira server go down mysteriously for days on end.

All in all being affiliated with opensymphony has been nothing but a hindrance for osworkflow lately. The benefit in terms of marketing is more than offset with the inability to rely on basic project infrastructure. Chris Miller has felt similar frustrations when trying to release OSCache 2.0, where the release had to be held up for weeks on end due to our inability to ensure the javadocs on the website are updated.

Ah well, to cheer myself up, I’ll hurl a few cruel jabs towards webwork2. I note with much hilarity that the project has now been ‘in development’ for 10 months, rapidly approaching the year mark. It is used by a handful of people in a number of mostly toy apps. API’s still change on a day to day basis. Looks like Pat has finally woken up to the havoc that Jason and friends have wreaked on the codebase (not to mention idiotic rewrites just to up the coolness/masturbatability factor) and is now busily undoing the retardation and restoring webwork1 type behaviour. There’s hope, sure, but I for one am rather dubious of a framework that brags of simplicity and ease of use yet has taken almost a year to arrive at beta2 (due Real Soon Now).

JGraph, for those of you who don’t know, is an opensource swing component to handle all things graphy. It’s a component you can slap in as you would any old regular swing widget. It will draw pretty pictures, let you drag them around, and generally indulges you as you make a nuisance of yourself.

JGraph though has a number of fairly horrific flaws. First of all, it’s impossible to build. Now, I’ve seen my fair share of badly written ant build files. I’ve seen build files that force you to define environment variables. I’ve seen build files that require defecating all over your ANT_HOME/lib dir, I’ve even seen build files that don’t check for directories before they try to output stuff into them. What I have not seen is a build file that plain refuses to do anything useful. First, the build.xml is not in the top level dir, it’s in a directory called….script. This directory also has a motley crew of bat and sh files. (one each for ant, compile, doc, make, and port!). The documentation, needless to say, goes out of its way to avoid giving any hints as to how this lovely component can be built. Just to spice things up a bit, there’s a TransferHandler.java file sitting there in the script dir. No matter how I run ant, no matter what directory I run it from, and no matter what env vars I specify, I cannot achieve build nirvana. The best I can do is get the build file to feebly create some directories then fail to populate them with anything meaningful.

Thankfully, it’s possible to download a reasonably recent release. Sadly though, the build hurdle was a sign of things to come, rather than a freak accident.

JGraph allows you to pretty much do anything with graphs, and a lot of things you shouldn’t do with them. Unfortunately it suffers from trying to be far too clever. For example, by default it has a hugely annoying set of key bindings that I’d bet most graphs do not require or even support. Things like cloning, grouping and suchlike. The approach in general seems to be ‘enable everything and force to the user to disable it’, with the cutesy opensource approach of never actually specifying how to disable stuff. Another oddity is that the documentation goes to some length to explain the distinction between graphs and trees (and how the latter is a subset of the former), yet JGraph itself often tries to uncomfortably shoehorn itself into some of the craziness that goes on in javax.swing.tree.

Then there’s the design issue. JGraph brags of being very much in the Swing mold. Amazing, it’s managed to outswing Swing. Not only do you have fullblown MVC (which swing does NOT have), but there’s also an extra layer of ‘views’. For anyone who has done a lot of swing work and tried to be strictly MVC, you’re probably twitching in discomfort now at the thought of having to deal with such a horrible design. It just doesn’t work. There’s no way of enforcing the contracts, and you end up with a big mess of classes where things are kinda-controller-kinda-model-kinda-view-kinda-somethingelse (varying degrees of each). Graph insertion can be done in so many ways that invariably, the model is modified by the view, the model modifies the controller, and there’s you crying like a little girl being drowned in a tub of congealing spaghetti.

Setting all that aside, there are also some foolish implementation choices. For example, there is an Edge.Routing interface (yes, it’s an inner interface, joyjoy). This interface gives you a list of points, and you’re free to define your own router and modify these points. The advantage of allowing this is that you can handle vertices that join onto themselves, or defining 90 degree angle lines between vertices. The problem with this though is that edges are often NOT just a list of points, and can well be curves of some sort or another. The current implementation, from what I can tell, makes it impossible to have a custom routing algorithm that does loops for self-references.

While it provides for huge flexibility, there are many points where the design was simply not thought out very carefully, and you end up having to contort yourself into all sorts of unseemly positions just to get it to look vaguely like what you had in mind.

Having said all that, JGraph really isn’t all that bad. I just wish it focused more on its core competencies and followed the ‘less is more’ principle, while having a rich set of class/libraries/sample code that handle all that extra gunk.

It’s that time of the week again I’m afraid. Time to go through a mostly boring recap of responses, taunts, and veiled threats.

First, regarding my proposed JRoller TOS. It should be clear to even the halfwits amongst you that there is absolutely no way in hell a single one of my items will ever be put in place, so you can safely straighten your panties now. The one thing I’d like (in all seriousness) is some requirement to be very vaguely Java related. Sadly though I doubt that’ll get on the list either. Rick Ross’ wife now has a blog which is (refreshingly?) devoid of anything to do with computers, let alone Java.

The comments on that thread though deserve some mention. I’d kindly request that people comment in English. Yes, it can even be Grotty English. Posting in Spanish is highly irritating, because I (and pretty much every non-Spanish speaker out there) is incredibly unlikely to bother finding a translation of your comment, so your witticisms will be lost and you’ll be sad. The second issue with comments is people embedding html. It was cute the first couple of times, but please try to avoid it unless it’s mildly amusing instead of destructive/stupid. Any comments engaged in deliberate sabotage will be summarily executed.

Another point regarding commenters. Please please, for the sake of sanity and general good behaviour, pick a name and stick with it. Having multiple people called ‘Anonymous’ is annoying. At least I know that there are only two ‘Anonymous Bastards’, but one would be ideal. Pick any name you want, just be consistent!

Perhaps I wasn’t too clear in my NullPointerException rant on their proper usage. There is nothing intrinsically wrong with throwing them. The problem is when a developer doesn’t explicitly handle it or mention it. Hell, even a javadoc comment saying ‘this method can throw an NPE if param1 is null’ would be a godsend. I was also horrified, shocked, and downright scared when someone mentioned the ‘Null Object’ pattern. From what I can tell, this object is in every way a null, without the telltale sign of passing tests like null equality and throwing NPE’s. I can get my eyes to bleed just by imagining such code. As a couple of people wisely mentioned, there’s absolutely nothing wrong with explicitly throwing an NPE, as long as it’s helpful and says exactly what is null.

Finally, credit to Jason Carreira who hit the nail on the head with what’s wrong with GUI tools (even incredibly helpful easy to use ones). It might be faster the first time, but doing it 20 times over just results in an angry irate user. We all know that when we have angry irate users, we have people who dislike their lives. When we have people who dislike their lives, we have people wondering whether it’s all worth it, the pain, the price one pays for all the suffering, and suchlike and so forth. When that happens, well….THE TERRORISTS WIN.

With every new EAP, I have a brief period of intense anger and frustration. Rarely does this spillover into a good old-fashioned bile though. Unfortunately the downside of that is that all that anger and rage simply get bottled up. At this point, I am a bottle of well shaken anger and rage, and this here is my attempt to open up the cap.

How hard can it possibly be to have a release that kind of sort of works? Sure, 944 worked sometimes. 957 also vaguely works. Those of you who insist that they work flawlessly can fuck off, your joy is of no comfort to me. Really though, the quality is abysmal. After all that excitement and eagerness in the run-up to 957, imagine my surprise and dismay to find that it’s a hell of a lot less usable than 944 for me.

As tedious as it’s become to endlessly repeat this, I feel compelled to point out that there aren’t any new features I’m gleeful about (new junit is nice, cvs is still sometimes more annoying than the old version). So the ONLY thing I look forward to in new EAPs is stability. At this point, I don’t think this is an unreasonable expectation. We’re told that the final release of 4.0 will be out in 6 weeks or so. Within the first 10 minutes of using 957 I had filed 4 bugs (via the lovely auto-reporter). These were all new bugs that didn’t happen in 944. Of course, there were still some old favourites that happened in 944 that still pop up for entertainment value in 957.

Of course, no rant about IDEA is complete without bitching about performance and memory. The 3.0.x releases can run for hours before requiring a restart. In the 9xx builds, part of my work habits is to restart IDEA every hour or so. The junit test run class chooser takes a couple of days to show the testclasses available (that is, if you have less than 10. If you have more, a new EAP will likely be out before you actually get to see the list). For the sake of variety, that chooser will also now and then bitchslap you with an internal error.

Now, don’t assume that these are all OSX bugs (a number of people have often responded to my complaints with the ‘IDEA is only really fully supported on Windows, so shut up’ argument). I’m now forced to use it on Windows, and a lot of the problems happen there too. Of course there is the extra fun of the OSX specific issues (for example, the known issue where installer hasn’t been double-clickable for the last 3 EAP builds, and has to be run via command line instead).

There’s also a general feeling of malaise and stagnancy about the whole thing (which might well exist only in my mind, I concede). Features present in 3.0.x have been in the process of being ‘reworked’ for months now. There is a very vague promise of opening up the J2EE API ‘at some point’, despite the fact that previously we had reasonably functional generic EJB support that is now restricted to Weblogic only. We had compile to sources and multiple output paths. We had up to date javadocs for the open API. We had all the developers that have now moved onto bigger and better things (the 2-3 new products they’re working on). Love was in the air, back in those days.

I love IDEA. I love it passionately and intensely, I love it enough that I’m willing to hunt down and kill Eclipse people in the name of IDEA. That love unfortunately places a great burden on it; it can hurt me so easily, the slightest insults and inconveniences are seen as major betrayals and disappointments. I can’t help but repeat that hackneyed old phrase…..I miss the good old days.

Using any application of size, it’s almost inevitable that you’ll be slapped in the face time and time again with a bevy of NullPointerExceptions.

It’s hard to come up with a reasonable explanation of why these exceptions are so prevalent and commonplace. In fact, I have yet to come across a single application server that has never barfed out an NPE at some point or another.

Granted, in most cases it is the fault of the user; providing less than stellar input. J2EE descriptors are rather easy to get wrong, for example. You’d think though that a company that is able to muster up the resources to build a J2EE stack would be able to expend the fairly minimal amount of extra effort it takes to assume that users will pass in bad info, and handle it in a civilised and sociable manner.

JBoss (sorry, couldn’t resist) is a good example of that incredibly half-assed piss-poor lackadaisical approach. Very often, you get an NPE deep inside of JBoss code. The NPE is often repeated 3-4 times, wrapped inside of 2 or 3 other NPE’s. Sometimes you’re lucky and you actually get a helpful message that subtly hints of a vague area to begin sniffing around. Sometimes it’s particularly cruel and reports the wrong component entirely as the culprit, thus leading you on a wild goose chase familiar to those poor bastards trying to find decent documentation for any open source stuff.

Sadly, this particular ailment isn’t restricted to JBoss. JRun will also barf out endless reams of NPE’s if you so much as sneeze in its general direction. They also are of the ‘lets nest exceptions, it’s very helpful to end users’ school of thought that Weblogic now belongs to as well. Luckily, both of these servers will tend to hide that one crucial line of information describing the error you need in that behemoth of a trace. So if you do read it carefully, you might actually see it.

It really isn’t a very hard concept. Always expect bad input. If it can be entered into your code, then someone somewhere will enter it. Null checks are trivial and buy you a lot of love if they report clearly and coherently what is null, and why that’s bad. Don’t nest it, don’t obscure it, fail fast and helpfully.

I’ve recently had the (dis)pleasure of needing to convert a bunch of code that uses log4j to use JDK 1.4 logging. Why might one want to do this, you may well ask. Well, there are a couple of reasons (neither of which is THAT compelling, but hey, it’s an opensource project, so it’s all about defining ludicrous requirements and masturbating to bizarre code fetishes).

The first reason is that log4j weighs in at a whopping 350k. The code for this project (including the one other jar it requires) it 80k. So, one would (rightly) feel pretty stupid if one is lugging around a 350k jar just to log some stuff in 40k code.

The second reason is that one of the requirements for this project is a severe shortage of external dependencies; so log4j had to get the axe.

I hadn’t had much exposure to JDK 1.4 logging previously, beyond having to curse at people using jakarta-commons as a wrapper to it. The annoyance factor of java.util.logging is surprisingly high for a variety of reasons.

First of all, the default formatters are pathetic. If you want to convince someone to move away from System.out.println, you do NOT replace their terse clear statements with 2 lines of crap, including a java.util.Date.toString() in every damn message. Even if you do ‘help’ them with this ludicrously verbose output, at least have the decency to make it customisable, and allow for a more terse response. Of course, if you provide that verbose output and want to really spit in your users’ eyes, call the formatter SimpleFormatter.

In addition to the horrific output from this default formatter, it’s also very poorly implemented. Calling date.toString for every message pretty definitely falls in the realm of cruel and unusual punishment (with a MessageFormat too!).

So, the first step was to write a custom formatter that produced vaguely sane output, while ensuring performance is slightly faster than Christopher Reeve in a 100m dash.

Consistently though, the rest of the API is likewise plagued with poor performance. Objects are created with gay abandon. Checks for log levels happen far too late. The only way to do it justice is to plug in your own implementation for handlers, loggers, formatters, and filters. Mind you, it’s pretty easy to beat log4j performance just by filling in a subset of those.

Then there’s the configuration nightmare. The option of either a class or a file path is not exactly the height of configurability. What’s so bad about url’s? Why not allow for properties files looked up in the classpath?

Surprisingly enough for Sun, the documentation is also not as clear as one would expect. I fumbled, I googled, I mostly flailed about helplessly trying to get anything chattier than INFO to show up (for some reason, just defining a global level didn’t work for me).

The level names also deserve a mention. Why on earth are there three different kinds of ‘fine’ness? The English language has an awful lot of words to describe this sort of thing. Surely to god it can’t be that hard to come up with something more helpful than FINE, FINER, and FINEST.

There’s also the pain of logging exceptions. There are no convenience methods to do this, you have to call the log method, and pass in a Level, message, and exception. A few more methods would have gone a long way in winning the love and adoration of the masses.

I’m usually quite a fan of Sun’s API (at least, ones that aren’t designed by open-to-public JSRs or apachepoo). While often performance isn’t particularly stellar, the API design is more often than not elegant and is exactly what 99% of developers need. One has to wonder what sort of accident or oversight led to the current state of java.util.logging.

For those of you who can’t wait until we get the official JRoller terms of service, here is my proposed (well, wishful) TOS.

Purchasing commercial software is a joyous event indeed. There’s nothing like the feeling of paying for something, knowing that you’re doing your part in lubricating the wheels of commerce, helping someone earn a decent living, and/or ensuring that some random family you’ve never heard of will sleep with full bellies tonight. It also gains you some sense of exclusivity, you’re now in possession of something that not everyone could get. It’s not some open source crap that some pizza faced kid splattered out, to be used by anyone mildly aware of how a browser works.

Still, sometimes the whole purchasing experience leaves a bit of a sour taste in one’s mouth. A leading source of sourness is CPU-based pricing. I personally am at somewhat of a loss as to the rationale of this methodology, and would dearly like to learn about rational justifications for it.

First, if it were a matter of more cpus==more performance==more cost, then that would make sense. Alas, that doesn’t seem to be the case. You pay for the number of CPU’s on your server, not the number you’re actually planning on using. So if your production servers happen to be very beefy machines where your app is one of many, you still have to pay a king’s ransom in per-cpu fees, even if you’re perfectly content to just use one or two of those cpu’s.

Secondly, pretty much everyone knows that an extra CPU will not give you a 100% increase in performance. So again, charging double for significantly less than double the performance seems like a bit of a scam. After all, you could just slap on another linux box and cluster the two, thereby halving the load on each, and thus getting closer to 2x performance. Granted, linux kids tend to be the cheapo poor variety of deployers, where per-cpu pricing doesn’t sting that much,as you’re unlikely to have more than 1-2 cpu’s in there.

Even more ridiculous is the sticker price on many per-cpu ‘enterprise’ products. I have yet to hear of a single entity that has paid sticker price for something like Weblogic or Websphere. In reality the price is far far lower than what the official number is, sometimes by as much as 50-70%, with a lot of extra freebies thrown in like training sessions, free developer licenses and suchlike. So why have the ludicrously high price in the first place? I suppose it’s a matter of child psychology; you’re more likely to purchase something if it’s at a very high price and you’re offered it at a much lower (but still relatively high) price. The thought of ‘winning’ and getting a ‘deal’ blinds many people to the fact that they’re still being mugged.

Of course, I’m not advocating that you commit developer suicide by choosing the nearest free pile of dogturds deposited on your doorstep (sorry JBoss fans). I just find that products that have a per server price or per user price somewhat more palatable than the arbitrary cpu charges.

I have to say that lately, I’ve been quite dissapointed in the comments. While it’s nice to see that a bunch of people care about and want to ‘participate’ in the general mayhem that they’re moved to comment, the quality is absolutely dire. As shameful as it is, I must concede that there is a not-insignificant percentage of my readers that are, basically, idiots.

If I were to stop using jroller, trust me, I’d be reasonably vocal and lucid about it. I would not allude to it or flimflam about and state in an indirect oblique way. So imagine my surprise when a bunch of morons decided that a post entitled ‘goodbye freeroller’ means I am actually leaving. Did you miss the actual content? It’s right there alongside the heading, you know. Freeroller no longer exists, it is now JRoller. I was simply bidding farewell to a friend.

Secondly, to the genius who pointed out that there is no such word as Grottesque in my anti-spelling rant, shame on you. As gauche as it might be to have to spell out jokes to people, it pains me that something so blatant was missed. Grottesque means ‘in the manner of a Fred Grott’, it’s an added bonus that it hints at grotesque in the interim.

Regarding unit/integration tests, I do see the difference (thanks for contributing intelligent comments in its defense though, Jason and dkfn). The problem is that I’ve found that in reality ‘unit’ tests that test that one piece of code and it alone in isolation often becomes quite an awkward test, once you start chucking in dynamocks and the like. I haven’t looked at the xwork tests yet, but based on my usage, the setting up of inputs/outputs/expectations in a dynamic mock is still cumbersome and very ‘wordy’ code. Admittedly, the speed benefit can be significant, so in that case it could be worthwhile to add the extra dependency/complexity/time investment to get it set up just right.

Finally, as dirty as I find the whole experience, I’d like to clarify a couple of things to the incestuous javablogs crowd. I did not leave any comments on Joseph Ottinger’s blog. The ‘Fate’ who posted there is not me. While it is mildly amusing to see him and Chiara go at it. Have your little spat in private, and keep me out of it. It’s hard to express how little interest I have in that sort of gossipy/let-me-see-what-I-can-do-to-get-more-traffic crap. I hope I haven’t been hoisted by my own petard.

I managed to restrain myself from the almost obligatory knee-jerk reaction against the switch from freeroller to JRoller. However, that is not to say that there aren’t some…ahem…’concerns’ of the how and why of this endeavour.

So, why was this change done? Who gains what by it? It seems odd to go through a redirect change that breaks a bunch of things for no obvious gain or selling point. I’ve yet to see a rational explanation of why the freeroller.net name is no longer to be used. All one hears from the javalobby crew is how great JRoller is, and what great things they have planned for it. Suddenly it’s a fact of life and if we all say it’s great loud and often enough, people will forget to ask why on earth it happened in the first place.

Certainly, it’s not that the freeroller server/service is significantly improved or enhanced. It’s as stable as freeroller was. All the sudden move seems to have done is resulted in a number of irate users, who had to re-add their blogs to javablogs. In addition, search is now completely broken (granted, it was useless and usually non-functional, but at least it didn’t 404).

The switch also resulted in the illustrious Rick Ross deciding to have a blog on JRoller. This blog, needless to say, has the usual overdose of Rick Ross syrupy fun. The poor guy is endlessly surprised by how cool everything is, and gushes marketspeak delivered in that earnest-yet-serious-but-also-someone-you-can-relate-to-yet-wants-to-be-a-father-figure sort of tone.

Part of what is/was so nice about freeroller was the sheer incompetence involved. It was basically a bunch of guys bungling about ineffectually, who made up for their lack of skill/patience/greed/dedication/interest with huge doses of enthusiasm and a free spirit. Dave Johnson is a good example of this. From what I hear, roller was written as a learning tool, a way for him to see what all this j2ee stuff is about. He copied code with reckless abandon from other more authoritative sources. It’s nice to see that this habit is alive and well; when I reported an issue with the rss feeds for roller being hopelessly non-spec compliant and a bizarre mixture of various specs, he pointed out that he had copied the format from someone. Of course, instead of following the spec url I had pasted in my error report, his solution was to find someone else to copy who hopefully had a more conformant feed.

It’s also a shame that new logins are enabled again. Javablogs is practically useless as an aggregator, its algorithms for updating/displaying entries seem based on randomness and time of month rather than anything matching reality. Freeroller (with disabled logins) became a pretty decent source of new entries. Now that logins are enabled again, the front page is cluttered with ‘new posts’ and ‘I now have a blog!’. So can you JRoller folks please please get rid of that automatic FIRST POST nonsense?

Last but certainly not least, let us pray for the dearly departed and sorely missed &apos. It embodies the entrepreneurial wild-west spirit of freeroller like few other things did. My thanks to Anthony Eden who at the time realized the history and importance of that little bug, and understood that freeroller just wouldn’t be the same without.

One huge downside of working with continental European developers (or inheriting code from said developers) is that now and then you will stumble upon some idiot who thinks that it’s perfectly sensible for an international company with offices all over the world to have code written in their native tongue. For example, using German or French class, method, and variable names. For all intents and purposes, code like this is utterly useless to those poor saps who went through the effort of learning English precisely because their native tongue just isn’t that useful in a global sense. Debugging code like this is an exercise in futility, you’re forced to stumble about in the darkness, and the likelihood of being eaten by a grue is at a maximum. Use English, dammit!

Having said that, there are few things as likely to give a bad image to an author as language ineptitude. The way that we’re wired, someone who is unable to communicate coherently and clearly is far too easily labeled as stupid and dim. Of course, typing errors are a lot more forgivable, provided it isn’t a Grottesque orgy of fapping helplessly in the general direction of a keyboard. Spelling correctly is not an art, the rules are well defined, and there are a few hundred ways of spell checking whatever you’ve just chundered out.

Of course, there’s the IRC retard brigade. These people delight in popping onto #java on efnet for example, and farting out such pearls of wisdom as ‘ne1 got help 4 me applet?’

The problem is that while the emitter of said travesty will proclaim that IRC isn’t school, that it’s convenient/faster, he seems to not realise that his horrific abuses will pretty much ensure that he will never get any sort of help until he brushes up on his language skills. Helping someone curious to learn who takes the effort to clearly and coherently spell out their problem is a vaguely satisfying endeavour. Helping a brain-damaged two legged animal inflict their incompetence and idiocy on the rest of the world is far less so.

In this day and age, pretty much everyone agrees that unit tests are a good thing. Some of the more fundamental fanatics will even go so far as to worship at the shrine of TDD, rather than merely practicing the benign form of unit tests the majority is comfortable with.

However, it is important to be aware of a rising new sect that casts aside all the common sense regarding testing and testability that has been built up over the last couple of years. This sect is intent on testing everything and automating it all, ignoring the very basic laws of common sense and human nature. This abomination has a name, and that name is….HTML TESTING!

It is positively frightening how many projects out there promise you unit testing of webapps through some sort of html magic. Ranging from stuff like representing html as a DOM tree that can be tested against, to searching for particular strings, to filling out forms automatically, and so on.

In the name of all that is pure and good in this world, cease this madness! This is yet another case of people desperate to apply their newfound hammer to every single situation.

Here’s a crazy idea, why not use what people have been using for decades? Proper test scripts that your QA people will go through, and verify that everything looks right and behaves as expected. The medium in this case simply does not lend itself to clean automation; html is viewed by people. There are browser quirks, there is context, there is the whole realm of HCI (human computer interaction) to take into consideration. You pathetic little junit test will not even come close to testing any of that. Good luck using it to detect a missing tag somewhere, or a bad spelling, or a misplaced div. When your html guys change your page, good luck adapting your cumbersome testcase to the new html structure. Sooner or later you’re bound to notice that for every 10 minutes of html change, you’re spending an hour updating the testcase. Surprisingly, that still seems to leave many people undeterred, and gleefully praising their end-to-end testing of their webapps. For all you people saying that it still provides some measure of insurance, a convenient little test that is better than nothing, I say to you that the negative side effects of this and the false sense of security it gives far outweight the benefits.

We all love unit tests. They make us feel warm, fuzzy, and give us that comfort zone that is often our only security in a world gone mad. Lets use them where appropriate, instead of turning them into yet another source of horror and pain.

Thanks to everyone who sent in their own examples of pain and horror of bad code. As the saying goes, when you laugh, the world laughs with you. When you cry, inflict your pain on the world so it cries with you.

Inspired by all that bad code, I feel that not enough attention is being paid to that other evil-that-can-barely-be-named, bad javadocs.

Every time I see javadocs unmodified from their generated-by-an-IDE form, I feel like grabbing a blunt object and repeatedly stabbing the author in the face until there is nothing left but a bloody pulp. There are few things as offensive as 5-6 lines of absolutely NO new information.

For example, people who like to have such gems as @param myvar. What on earth does that tell us? That the method takes in a parameter named ‘myvar’? Isn’t that blatantly obvious from the method signature? How does this merit all this extra wasted space? Alongside this horror, there is the despicable @return aString taunting us with its unhelpfulness. The same applies to throws docs listing just the name of the exception.

If you want to provide javadocs, great. Anyone using your API will be thrilled and will think good happy thoughts about you. However, I cannot stress enough how satanic it is to provide the illusion of javadocs by having nothing there but skeleton javadocs that suck up valuable precious vertical space. Vertical space in this world, a world horribly skewed in favour of rectangular monitors, is a rare commodity. Lets not squander it so casually.

Another sin regularly committed (although admittedly, one that isn’t as horrific) is ignorance of line breaks and how the standard javadoc doclet handles them. Where you put your full stop (or period, if you’re American) is relevant and important. It isn’t something subject to whimsy or time of the month, there’s a logical approach to it that isn’t horribly complicated. The first sentence gives a brief idea of what you’re talking about. If you have more to say, it goes in the next line and starts off with a new sentence. Think carefully about the first sentence, you don’t want to be like POI, which has the description for the org.apache.poi.hssf.dev package saying a succinct (and wonderfully unhelpful) ‘DEV package serves two purposes’ in the top level index, now do you?

A lot of people these days seem to confuse mockability as a fundamental requirement for good testability. That to me smells a bit like a mavenisation (solving the wrong problem with clever tools, rather than addressing the root cause).

People will often preach that one of the advantages of webwork2/xwork for example is how it’s now perfectly mockable, therefore a superior product blahblah. Those same people will scoff at projects that are not mock-obsessed, and snicker at the worthlessness of their testcases.

The problem is that mockfans seem to be forgetting that mockability is nothing more than a way to overcome awkward API’s that do not lend themselves to being called easily from a testcase. Expectations are defined by a spec, docs, or suchlike. It’s reasonable to assume that things work as advertised. Nothing more, nothing less.

They have forgotten that if you can call the Real Thing from a testcase, then that IS in fact a superior solution. It takes into consideration real world usage, not some idealised (and often highly crippled) gimboid version. I realise that mocks are not really supposed to work, and should not be used as anything more than a convenient appropriately-named set of methods and classes when you can specify expectations and so on. However, back in the real world, method calls do not happen in a vacuum, and you are almost always relying on specific behaviour that involves setting up state, using a certain order of calls, and certain API magic that is abstracted away from you.

For example, using mock objects for JDBC stuff is very foolish. There are a number of java databases that will run inline with in-memory stores. So why not use a real database rather than someone’s incompetent fumbling attempt at implementing just enough of it to work? From what I’ve seen, I have yet to come across a single mock API that works perfectly out of the box, and doesn’t require tweaking of some sort. Adding that extra code to maintain in your codebase just to get a pale shadow of the real thing hobbling along seems…well…misguided. I’ve just added a testcase for ofbiz with mckoi in osworkflow with nary a mock in sight, so I’m feeling particularly smug about this.

The same argument applies to testing lucene (this post was in fact inspired by a mail to lucene-dev). There’s RAMDirectory there to play with, if the thought of writing to an FS in a unit test makes you cry like an embarrassed little girl. Of course, even that would result in you missing out on some bugs within Lucene’s FSDirectory. Thankfully if you run the lucene testcases on certain platforms, you’ll see that its file timestamp expectations are…ambitious, to say the least.

On the plus side, I’ve managed this far to not make any puns regarding mocking, so consider yourselves quite quite lucky.

Every now and then, we all come across pieces of code that are so monumentally stupid, so astoundingly incompetent, and so fundamentally flawed that one is unsure of whether to laugh, cry, or just pick a different career.

Even the dummies amongst you have come across stuff like this. The beauty of it is that the ability to laugh at said code and mock it horribly seems to have no relation to the likelihood of the mocker writing the exact same crap.

So, lets have a look at some examples. Note that these are all found in existing code, they are not contrived or made up. Some are from open source, many are not. Enjoy!

Imports:

To celebrate the tss thread whereby an overwhelming majority of users proclaimed maven to be a bloated sucky pile of moist dogdroppings, I think it’s time to shine the light on its failings in areas that don’t usually get much mention.

Briefly setting aside the idiocy of the concept of maven, and how it goes about doing things, lets examine the output of maven. Just assume for example that you have a retarded inbred oss monkey at your disposal who has the time, patience, and zealotry to actually set everything up for you, lets look at one of the results of this magic, the fabled ‘website for free’ selling point. Yes, I realise you could ‘do your own’, but that’s like arguing that you don’t have to use the ant built-in or optional tasks, you can always write your own set. What’s the point of using the damn tool if you’re going to invest in all the effort to ‘do your own’ anyway?

First, you get free maven advertising on your website. I’m sure that’s a solid stamp of professionalism right there. Next, you get reports, a lot of them. Reports are good, right? Well, not quite. You get stuff like links to your source code, a hideously bland list of your project team, links (more often than not, quite broken) to issue tracking and mailing lists.

You also get a source xref. This I’m sure was useful back in the days when people didn’t have suitable tools to browse source in a far easier and sensible manner than a stupid web UI. Java professionals will use IDEA. Even their retarded happy-idiot poor cousins will use Eclipse at the very least.

You also get a million JDepend generated metric results. I am completely and utterly baffled by these, I must say. Has anyone, ever, EVER cared about these? Nevermind end users, but has a developer ever looked at these and thought ‘hmm, I don’t like the efferent coupling and abstractness percentages in some of our classes, lets hold off the release’? In fact, has anyone ever used these in a meaningful sense at all, beyond some halfhearted masturbatory effort?

Then there’s a clover reports. Yes, very useful for developers, no argument there. Really though, how do your end users care about this? It’s a pretty graph to be sure, but surely the relevance of a graph is important in determining its inclusion? At the end of the day clover reports presented to end users boils to yet more pitiful masturbatory material.

Particularly hilarious in the TSS thread is some maven developer exclaiming how easy it is to build a maven plugin. He points to a webpage that walks you through it. This to me is the epitome of what’s retarded about maven, and why its developers just don’t ‘get it’. They’ve been so blinded by their own cleverness that they wouldn’t recognise simplicity if it sat on their faces and farted all day.

The ‘hello world’ maven plugin is a 7 step process. The ‘build’ file for it is around 60 lines long. Sure, it’s boilerplate code, but hasn’t OO 101 taught us that if you’re endlessly copying and pasting the same stuff, you’re doing something wrong?

Lets contrast this with an IDEA plugin. Writing an IDEA plugin involves writing a class that extends an IDEA class to put your hello world in, writing a simple (4 line or so) plugin.xml file, jarring it up, then dropping it in a plugins dir.

How about an ant task, given that maven is there to ’simplify’ ant stuff? Well, you subclass the appropriate ant class again, echo hello world, jar it up, and add a 1 line taskdef for it.

Having said all that, it’s truly uplifting and encouraging seeing all the negative reactions that people have to maven. There is hope yet in the java world, if tools of this level of retardation are shunned and cast aside. For the rest of you, the emperor has no clothes, move along now.