The BileBlog

Alright, just so nobody feels that I’m biased, I’m going to rant against one of my own projects (although I will cleverly place all the blame on someone else, but nobody’s perfect). Today’s winner is OSWorkflow.

First, a bit of background. Many moons ago Patrick Lightbody discovered opensymphony, and decided to be an active participant. He was/is an eager kid working at Cisco at the time, on some document management/workflow tool. He wanted to abstract it a bit and contribute it to opensymphony. Many of the core developers were rather lukewarm about the idea, but I was enthusiastic and eager for a decent workflow solution so I egged him on.

Thus was borne OSWorkflow (oswf from now on for the sake of brevity). The code was functional, sort of. I didn’t get too into it and used it for very trivial scenarios where it worked quite nicely. At the time it was EJB based, but when ofbiz became fashionable that soon evolved into a persistence abstraction layer and now supports ofbiz, hibernate, jdbc, memory, blahblah. All very nice.

The code however, oh the code! Now, Pat is a nice enough chap, and has many fine qualities. Unfortunately he’s quite defective in a couple of rather key areas. Nothing too serious, just…well…writing performant code, short concise methods, and anything that scales. Beyond these 3 shortcomings, he’s a talented fellow.

The real problems started when I foolishly decided to use oswf for a trading system that was expecting mildly non-trivial loads. Nothing too serious, just more than one a second. This turned out to be a ludicrous high load for poor oswf. For one thing, it made the ‘copy a propertyset (one query per key, plus another to get all keys) from the database into a map for every invocation (plus then persisting the map back to the propertyset)’ approach look quite…silly. Certainly an interesting approach though. Very pretty from the design view, to be fair. Just worthless in real usage.

Now, since oswf allows you to write custom classes and plug them in for things like validators, functions, registers, and so on, Pat decided that it’s worth having a class cache (as a static Map!). I guess nobody bothered telling him how classloaders work.

Worst of all, and this truly pains me because it’s STILL there (the previous issues have all been somewhat fixed), is the unhealthy obsession with statics. Frankly, any web/j2ee container should simply refuse to load any classes that have a non-final static field. It’s an insult to all that is holy. It makes me want to chew off my arm just to distract myself from the horrific psychological damage that seeing ’static’ does to any sane person’s psyche.

Still, why be so picky about the code? Pat is famous for changing things and then offering to maintain them, and winning by dint of insisting that he’s the only one doing the work so he should change it so life is easier for him.

A brief rundown of some of his party tricks over the last year:

While browsing various sites to pick on easy targets for tearing apart (TSS and JDJ were early winners, javalobby might be up soon if I manage to stave off boredom for long enough), one fact makes itself evident time after time; the astoundingly, mindbogglingly, horrifically pitiful quality of most articles.

Now, I don’t consider myself one of the best or most knowledgeable java developers in the world, but really, most articles are downright insulting in their content.

Javaworld for example is currently telling us that the presence or lack thereof of serialVersionUID has no effect on serialization speed. Apparently this is a performance myth. I’d like to meet some of those people who did think that this gives a significant performance boost, and perhaps bring back that oft-missed ritual of human sacrifice to one’s god of choosing.

Of course, whenever one of these trash magazines is strapped for content, the usual suspects are trotted out yet again. You can be pretty sure any given issue with have some nonsense about webservices (for all 3 people who care), a motley crew of editorials/opinions (mostly pretentious irrelevant crap ejaculated by some random person’s enthusiastic mental masturbation), and that old favourite; GoF patterns regurgitated with slightly varying sentence structure. Guess what folks, the facade pattern is not groundbreaking news, nor is decorator, singleton, factory, proxy, blahblahblah. Buy the GoF book for the love of god and read it quietly, without sharing your findings with others. If you MUST share, point people at the book, not your pathetic ‘I just discovered something amazing and must repeat it verbatim’ public outpouring.

Perhaps this is all not surprising. Perhaps it is a reflection of how astoundingly incompetent most people are, that they need hand-holding with performing such simple tasks. I do find that difficult to believe though. Almost every developer one comes across is keen to dismiss most other developers are stupid and ignorant; they can’t ALL be right. Chances are that you, dear java developer, are an average developer, or very close thereabouts. Don’t be fooled into thinking that the odd particularly retarded so called ‘developer’ you come across is the norm. YOU are, you conceited pretentious turd.

Anyway, I digress. Back to the point at hand. In lalaland, we’d have articles that are actually aimed at professionals. Articles that aren’t busy telling us how great Eclipse and IDEA are, but perhaps ones that expend some effort into providing real technical content, not tawdry opinions and endless pimpage of some product or the other.

While bashing TSS was a lot of fun, their sins pale into comparison with the real horror and pain that the JDJ website inflicts on its hapless visitors. I realise that their purposes are somewhat different; one wants to generate a lot of traffic and be seen as a mover/shaker type community site (quality of people who take you seriously isn’t nearly as important as their quantity), while JDJ is supposed to entice you to purchase their magazine, I’d imagine.

My first burning hatred sensation caused by JDJ happened about 4 years ago or so, when I decided that it’s time to stop all the spam they’re sending out, and dutifully followed their unsubscribe instructions. The email I sent bounced back, and there was no way of getting in touch with anyone to get oneself removed from the list. Ohdear. They now go into my spambucket (which never gets checked), but still, it would have been nicer if the problem were fixed on their end rather than mine.

Still, that doesn’t quite explain the abysmal website they’ve conconted. They still use framesets, giving the whole site a mildly amusing 1999 look. More disturbing, the body area of the frontpage is nothing but ads.

To save you from the effort of scrolling down, I’ll do so for you and report the further insults to injury being heaped upon us hapless victims. We have a JavaOne exclusive insight in the form of a ‘live’ blog (from June 11th). While the ‘live’ nature is amusing (for example, the use of not one, not two, but THREE exclamation marks at the end of a sentence), it looks rather foolish still up there almost a month later. The whole thing would feel somewhat less amateurish if someone took a scalpel to some of those exclamations.

Further down we have more advertising disguises as content in the form of ‘JDJ white papers’, usually vendor provided glossies urging you to spent your company’s hard earnt cash on their ludicrous dotcommie ideas.

More amusement is provided by Joseph Ottinger’s J2EE editorial, where he first points out that last month we had too much innovation, but this month we need more innovation (sorry Joe, but it IS funny on the surface of it).

Most of these articles are usually duplicated further down or somewhere else, it’s a neat trick that reminds one of restaurants that uses mirrors on all walls to give the perception of increased capacity.

The most offensive aspect of the whole experience by far though is the rampant advertising. It’s everywhere, you can’t read an article without 21 ads (count ‘em!) trying to muscle their dubious content into your field of vision. As a result of conceding all this space to these desperate companies, one is forced to scroll endlessly since each sentence is about 3 words long horizontally. Fairly short articles are split into 7-8 pages, presumably to maximise advertising exposure.

All in all, I would be an extremely happy customer of JDJ if I were an advertiser. My product would be ruthlessly pimped with saturation exposure to all and sundry. For anyone else, it’s a sad depressing experience.

I suspect that much of the blame falls on sys-con, rather than the JDJ folks themselves. Alan Williamson seems a friendly and nice enough chap, as do Jason Bell and Joseph Ottinger. It’s a shame that the delivery mechanism of their product is just so eye-bleedingly offensive.

It’s amazing how many projects out there seem to willfully ignore the very basic principles of DTD usage. So for all you dullards out there who still, despite having FOUR years to figure this out have yet to do so, here is a simple guide to making you look vaguely competent. At least, you will no longer be scorned horribly for being an xml dimwit.

Firstly, if your xml is in any way a sensible usage that god intended (ie, it’s not an abuse of xml like an ant script) then you really, really should specify a dtd. Why? It makes life much easier if you expect anyone else to have to modify or work with your spangly new xml file. It also provides rudimentary checks against someone specifying elements and attributes of dubious quality and/or quantity.

Now, having specified a dtd, you wisely put it up on a public server, so everyone can point to it (you’re an opensource monkey, you want to show your genius to everyone and have your ego stroked endlessly, for example). Your amazing new API uses a number of xml files which point to this public dtd. The next biggest mistake after not specifying a dtd at all is not having your xml parsing resolve known dtd’s locally. it’s amazingly trivial to register an EntityResolver that looks up DTD resources (eg, in mycoolapp.jar/META-INF/coolcrap.dtd), instead of forcing out a trip over the network. Why is this considered civilised? Well, people who work in more serious environments than yours often have to deal with severely locked down production boxes. These boxes usually have limited access to the outside world, and a bevy of firewalls to stop them sucking down or sending out gunk. So the poor sap who uses your non-EntityResolver-using library is stuck wondering why their app now takes two minutes to start up while the xml parser dawdles about waiting for the socket timeout to your dtd.

Now you have a dtd, it’s resolving locally, you’re halfway to conquering the world. The next crucial step is to document that dtd! Yes folks, amazing as it may seem, having xmlspy spit out a dtd is NOT sufficient in and of itself. You need to go through and explain what each element means, and if you’re feeling exceptionally kind, specify constraints that dtd’s are not rich enough to impose. You could of course go with xml schemas if you’re into cruel and unusual punishments, and get a kick out of validation that excels in performing terribly.

Finally, do not assume that your API is the be all, end all in its domain and is futureproofed. Amazingly enough, you will in fact release new versions. If you’re an opensource product, you’ll likely gleefully break backward compatibility, if just to keep your users on their toes; you can call it refactoring or cleanup though if you’re pressed for an excuse. If you want to take the moral high ground when doing so, you should version your dtd’s; this will enable you to frostily inform the ill-educated user that they should simply point to hoitytoityapp_2_1.dtd, fix the validation errors and they’ll be fine.

I am often disturbed by the number of people who read theserverside.com. It is so obviously a trash talk site yet so many seem to take it rather seriously, often expending great energy and effort into sharing their opinions and insight about some tawdry subject or the other.

First we have the overall layout. Clearly someone has gotten somewhat overexcited with a box that has one too many crayons in it. They also decided to opt for the ‘lets show the faces of the developers’ school of thought. To be fair though, the people pictured often look like professionals rather than escaped convicts, a la JBoss. Mugshots on a community site are generally a lot more palatable than on a site intent on projecting a ‘take us seriously, dammit’ attitude.

Still, we have plenty of things to drive even the mildest mannered design experts into extended bouts of wailing and gnashing of teeth. Examine if you will the bewildering style and variety of icons used. We have the obligatory lego blocks on the top nav bar. These often mutate to unshaded 16 colour counterparts by the time they’ve descended into the right nav area, usually mixed in with some externally sourced highly irrelevant image of some sort.

Speaking of the right nav, it seems to get incredibly overexcited in the ‘tech talks and events’ section, cruelly bullying its way over and using up almost as much space as the body of the page. I suppose those middleware courses have to be pimped more than your average right hand blurb.

Of course, all this is without even getting into the somewhat dubious content. The petstore and clustering debacles are fairly well known. Clustering arbitrary collections of appservers in a bizarre deployment environment, presumably to pimp up any vendor who pays the appropriate fees. A deployment that would make most java developers claw out their eyes and take up VB by Braille, back in the real world.

Some of the TSS handouts are also often quite enjoyable reads if one were after a chuckle or two. I fondly recall rocking with hysterical laughter at the fluff in their ‘J2EE vs .NET, which is best for you?’ handout at JavaOne a couple of years ago. Ahh, we were so young and innocent back then.

By far the most fun though is to be had in the user comments. It is here that most people make a name for themselves, usually by being complete and utter imbeciles. Any topic which mentions JBoss for example is guaranteed to bring out the whole hive, where they all spasm uncontrollably in the vicinity of a keyboard and ejaculate filth at one another until everyone else has been driven off. Entertaining reading to be sure, but hardly highbrow insightful material.

TSS has become much like slashdot, without the balancing effects of moderation and meta-moderation. A pissing grounds where he who squeals loudest and hardest will win through sheer persistence.

It’s getting a little bit tiring seeing every new project somehow try to shoehorn in dynamic proxies, bytecode manipulation, or some other form of hackery that makes the author feel clever and cool. I realise that these things go in phases, that this phase is akin to people discovering BeanInfo classes and adding them everywhere because they seemed awfully cool, but it’s still irritating to live through

I understand that often, usage of those two things makes perfect sense and it’s the most elegant way of solving a particular problem. Remoting comes to mind, why any vendor expects users to run a precompiler these days to generate stubs and skeletons is beyond me. I’m sure there are other legitimate uses.

However, I wish people realised that using reflection/dynamic proxies/bytecode enhancement is a distasteful act, and that some vague attempt should be made to avoid them. I realise the core JDK makes it possible, so arguably it’s there to be used. Anyone who has looked over the source of the core JDK though should hopefully know by now that using everything it offers blindly is a recipe for disaster.

So what’s so bad about these approaches? Well, they’re incredibly irritating to debug, for one thing. It’s hard to tell exactly what your bytecode was instrumented with, or find any source for that instrumentation. Dynamic proxies are even more impossible to poke around in. Good luck trying to decipher a dynamic proxy stacktrace too.

There’s also the performance issue, yes, I realise that these days it’s pretty cheap to use all these techniques, but a dynamic proxy for example is still measurably slower than a straightforward old fashioned interface call.

The problem is that it’s so much easier to use these techniques than spend the effort and time investing in a good design to accommodate your requirements. The hack value is high, there are classes of problems that can be solved by either bolting on these hacks, or spending effort up front in designing for/around them. No prizes for guessing which approach the ‘cooler’ java developers will go for.