The BileBlog

I am absolutely amazed that people can discuss the usefulness and production-worthiness of Prevayler with a straight face.

The genius of prevayler is not that it does anything innovative (it doesn’t), or that it provides incredible functionality (it doesn’t), not even that it is hugely robust and reliable (it isn’t). The genius is purely in the marketing. In fact, it is a shining example of an open source project that manages to play with the big boys using the same dirty tools.

For example, prevayler advertises itself as a persistence engine (sort of), but instead of comparing itself to similar approaches, it wisely chooses to benchmark itself against completely different products used for wildly different purposes. By doing that, it’s able to look you in the eye and gleefully proclaim that it’s 9000 times faster. Amazing huh, that storing something in memory is 9000 times faster than putting it in a relational database.

For the uninitiated, prevayler is basically 3 of 4 classes that allow you to record system state. It basically serialises stuff to disk. That’s it. The clever part is that it doesn’t do so all the time, oh no, it does so once a day. So you have everything sitting around in memory because, well, ram is cheap apparently.

The prevalence skeptical FAQ they offer is another work of sheer genius. Instead of comparing apples with apples, they decide to compare apples with spaceships. The questions all cleverly ask silly things like ‘but what about remote access/clustering’ with hilarious answers like ‘you’re free to use whatever you want! RMI! Corba! XML! Sockets!’. Transactions? You don’t need them! They’re an antiquated idea and pointless anyway! Most of the answers seem like joke responses to be honest, delivered with that devil-may-care-throw-caution-to-the-wind cavalier attitude. It’s cool, it’s hip, it’s also utterly, utterly useless for any serious usage.

I wouldn’t be surprised at all in fact if the prevayler team were to eventually admit the whole thing was a joke to try and see how gullible people are.

Another week marches by, and to celebrate, a new village idiot must be crowned. First though, the usual batch of corrections and apologies.

First up is ofbiz, thanks to David Jones for posting a very heartfelt defence of ofbiz, and pointing out that sometimes choosing simplicity/clarity over clever designs and patterns is more useful in the real world (picocontainer fans, reread that last sentence).

Regarding all the EJB comments, I’m quite surprised that most people seem to have missed the point entirely. The point of my rant was NOT to walk over the same boring old complaints (5 files per ejb, all the metadata in xml, difficulty of mapping to existing schemas). Those are all red herring type issues; standard complaints that get trotted out that have been addressed (by xdoclet, xdoclet, and middlegen, respectively). The idea was to highlight concerns as an ejb user, not as someone who is looking at it from a distance eager to whine and complain that EJB’s suck. An ejb user has already accepted that it’s a component model, thus inheritance and various other OO niceties aren’t as available (although it’ll be interesting to see the impact that generics will have on EJBs, since they will make inheritance quite possible), so the idea was to avoid meta-complaints, and to cite specific concrete implementation examples instead; problems that could be solved trivially by enhancing the existing spec, rather than design issues that need a rearchitecturing approach.

Finally, the crowning ceremony…this week’s undisputed winner is Fred Grott. Clearly very indignant at being so easily surpassed last week, he came out with all guns blazing. I know it’s cruel to harp on about his abysmal spelling, but really, it’s so hard not to, considering how incredibly easy it is to avoid some of the more blatant ones (eg, using JEB for EJB). Maybe English is his second language, although that excuse doesn’t hold much water as English is my second language and I’m able to (mostly) construct coherent sentences. I won’t even contemplate the possibility that he only speaks English. How is it possible to think lucidly with only half a language at one’s disposal?

There’s also his pitiful attempts at humour, his jokes are so embarrassing that one cringes at them, ashamed to even be seen reading them. He even stoops so low as to post links to his ‘humour’ and pointing out that it’s funny. Another favourite party trick of his seems to be to post articles with my name in them, no doubt another pathetic attempt at trying to spice up his articles with some trash talk.

So Fred, here’s your village idiot hat back, you showed those JBoss people how it’s done. You’re a true master of your art.

While perusing intellij.org in search of the latest and greatest IDEA plugins, I couldn’t help but notice how some of them are…well…useless. So a brief summary of the top losers might be in order. Note to any plugin authors: I am not mocking you, I am mocking your plugin. I realise you likely wrote it for fun and as an educational exercise, and take no responsibility etc. If someone wants to feel insulted, then I’d like to nominate people who use these plugins and/or asked for them in the first place.

I’m also going to ignore plugins which are clearly meant to be toys (connect4, google, tetris, sonar), and focus on ones which allegedly provide worthwhile functionality. The first of this sorry bunch is ConfirmExit. A plugin designed, presumably, for those incredibly clumsy oafs who keep hitting ctrl-F4 (or command-Q, or the linux equivelant) by accident. Perhaps a diet is in order, to trim those chubby fingers before that long IDEA session you’re about to attempt.

A Spelling plugin also exists! Initially I laughed hysterically at this silly plugin. Upon further reflection, it seems that people like Fred Grott do exist outside of ’special institutes’, and I guess they need all the help they can get.

Tagify is also another plugin worth noting. It will convert html, placed in html files (where it belongs, many would argue) into out.println() statements. The advantage of this plugin is that it enables you ignore the years of effort many people have poured into coming up with solutions to prevent you from ever having to do out.println(htmlstuff).

It’s pretty annoying that there aren’t really any cool IDEA plugins. Most seem like playful halfhearted attempts at hacking up something ‘fun’ in a day or two. The clover plugin though does look interesting, in that it actually does stuff in its own right that has slightly more than passing novelty value. Having said that, it’s hard to decide if the lamentable lack of decent plugins is due to IDEA having all the cool things one would want built-in, or whether the openAPI is not rich enough for anything beyond gimmicks.

Now and then, you will invariably come across someone who smells a bit anti-opensourcey. You know, someone who will cuss JBoss, or will perhaps say that linux is not marriageworthy, or that RMS is a few pence short of a teapot.

In such situations, many people flouder, and cannot decide on how to best drown out/stifle this harsh and irrational criticism. So, for all such situations, here is my guide to putting those inconsiderate people in their place.

The first line of attack is in pointing out that the accuser works for a commercial entity, thus is not entitled to an opinion and is incapable of being objective. This is a very effective technique against almost anyone you’ll come across, since chances are very high they have some kind of affiliation with some kind of money-making scheme. So if you’re ever upset with any opinion Cedric Beust has, for example, simply point out that he works for BEA and thus cannot possibly have any kind of meaningful point to make.

If however you’re after tried and tested methods, the jealousy line is also famous in its effectiveness. Clearly, anyone who criticises an open source library/project/code without having their equivelant and superior (and also open source) library/project/code is suffering from acute jealousy, and is just lashing out wildly to hide their own inferiority complex.

You could also take the moral high ground. This attack is a bit more complicated and mystical, as it involves cryptically proclaiming the moral bankruptcy of closed-source, and imbuing code with the dubious quality of ‘wanting to be free’. While your foe looks perplexed at your zen-like refutation, you need to follow up with comments about how commercial closed-source interests are living off of obsolete business/licensing models, and that time will prove that open source is the only economically viable path for software. Beware though as this theory, while 100% accurate, has yet to be proven by real life. Many commercial entities are taking longer than expected to die off from having antiquated licensing schemes or closed source.

Finally, if all else fails, play the poor man’s card. Proclaim that it’s free, and that free stuff, by dint of requiring the consumer to give up nothing, is inherently providing a net positive. Clearly anyone who refuses free stuff is insane or at the very least highly delusional. Be warned though that your protagonist might retaliate with the fact that cost is not always monetary, and that they value their time or some other such nonsense. In such situations, scoff arrogantly and repeat one of the above retorts as required. The key is to inject more exclamation marks with successive iterations, and/or to speak more loudly. Wild hand gestures can also be effective. If dealing in an online medium, use your hive antenna to call in for reinforcements, and overwhelm your foe by sheer force of numbers.

Ahh, I remember it well, that heady spring of 2002. Winter was being chased away by a determined April, intent on reminding us all that life isn’t so bad after all. America still had some some of the world’s sympathy, the mean old Afghans were a thing of the past, and Homeland Security was but a twinkle in Tom Ridge’s eye.

Meanwhile in the Java world, a punk still in school by the name of Patrick Lightbody was merrily stomping all over OpenSymphony projects; Adding his own personal wishlist and useless features all over the place. Getting away with it too, sadly, due to the dubious excuse of being the only one willing to do anything, good or bad. Another committer, Matthias, was busy upsetting the old guard by reformatting their code and checking it in. It was fun and games all round, life was exciting, love and hate both competed for our top emotion of the day.

It was in this crazy spring that the Ofbiz entity engine made a name for itself. Scorched by the false prophet of entity beans, fashion victims everywhere needed a new leader. One that would remove type safety, one that would make them forget anything to do with EJBs; a leader that was simple, yet alluring and sexy; it had to be changing daily, and require cvs versions to be of any use. Stable builds implied stagnation, and lacked that essential danger element.

It was at this time that Ofbiz mania took hold of those ‘in the know’. Support for Ofbiz persistence was popping up everywhere. Time honoured traditions of encapsulation, strong type safety, and abstraction were cruelly cast aside by the rebellious young hotheads.

That is not to say that everyone rushed lemminglike into this uncharted promised land. There was some that dared express some hesitation, and with small fearful voices voiced bafflement at the stripping away of all things OO. Needless to say, they were ruthlessly ignored. After all, the proof is in the pudding, and JIRA quickly became the poster child for the Ofbiz EE, compelling evidence that it is a wonderful and magnificent thing, OO be damned!

Before I lay into poor JIRA, I’d like to point out that Mike is a fabulous guy (hell, I’m having sushi with him next week where we’ll giggle about this). I also bought the first 5 JIRA licenses ever I think, to support this wonderful new app.

All is not well though! JIRA unfortunately fell for the ease and prevalence of Ofbiz’s GenericValue. It is difficult to find an action class or page which somehow does not directly talk to GenericValue. Abstraction has long since been cast aside for convenience. This is all good and well, since it makes life easier for developers, and new features and so on become very easy to add. Sadly, this does come at a cost. The cost is being locked in a death embrace with ofbiz. It is absolutely impossible (well, not impossible, just rather tedious, boring, and difficult) to decouple JIRA from Ofbiz and plug in another entity engine. Why would one want to do that? Well, why not? We integrate JIRA into our big fat portal app (EJB based), and having two orthogonal entity engines seems quite irritating.

Now, I’m not saying JIRA should automatically support EJB’s out of the box. However, I rather like the idea of just allowing for that possibility. In my opinion, persistence these days has become so orthogonal to business functionality and concerns that it should be as decoupled as possible. One should be able to merrily switch functionality without much knowledge of the persistence mechanism, and vice versa. Cuss EJB’s all you want, but the session facade pattern works wonders here. Sick of entities? No problem, you can just use the same entity interfaces, and have your session beans use hibernate to persist them. Your business logic won’t have a clue what just happened.

I just feel bad for all those people who committed to Ofbiz, and now don’t get to play with the latest and greatest persistence engine (which changes every few months, mind you). Oh the perils of having a real product to maintain, and being answerable to real customers!

In the true spirit of opensource, I’ve decided to present people with the wonderful oppurtunity to give back some bile.

Have you ever read a name that sounded familiar, but were unsure of what to think of them? Ever seen someone casually say ‘well Rickard thinks…’ and wondered who on earth this Rickard chap is? How about overhearing ‘Fred Grott is a dyslexic twerp’ at a nearby table at lunch, you want to participate, but you just don’t remember anything about him.

Well fret no more! The BileBlog will come to your rescure with a ‘who’s who in java’ list. Amaze your friends with your pithy ignorant one liners! Women will flock to you, drawn by keen insight and prophetic ability to sum up any given person in a few cruel heartless words.

So, I am accepting submittions for short bio’s for pretty much anyone. Some ground rules first though. Random person X won’t get an entry on the list. They have to be someone with some measure of visibility (open source committers, obsessive bloggers, product developers, etc). They also have to be vaguely java related.

About the bio’s themselves, they have to be reasonable short (anything from one line to a short paragraph). They also have to include something negative. For every positive thing you feel compelled to say, you must provide at least one negative comment. It also has to have some kernel of truth to it. Nobody is off limits too, feel free to submit cruel summaries of me, and I’ll post it. Here are some examples:

I’ve had the displeasure of working with the fpML spec (financial products markup language) for the last few days, and the one glaring fact that seems to present itself every minute is what a terrible terrible idea it is to use XML (with a bucketload of schemas or dtd’s in tow) for everything. This spec (to save you the bother of looking it up) is supposed to make life much easier for sharing and dealing wih financial derivatives. The main argument for this ’standard’ is that currently, the counterparties involved have to spend a while getting to know each other and agreeing on a data format (and more importantly, the data itself) to use. There’s a bewildering range of technology used. Some financial institutes are J2EE’ed to the hilt, and can easily offer you an interface in the J2EE API of your choice. Some like receiving very many faxes. Most are somewhere in between. So the effort to have these two firms talking to one another varies somewhat.

FpML cleverly states that by adhering to this spec, you’re removing all this effort. It’s certainly an interesting point to make. Of course, if you were the read the spec you’d realise that for any given firm, it’ll define a dazzling array of completely useless and unrequired elements. It also allows for an equally dazzling array of validation schemes. They provide defaults, but realistically, one often ends up having to define yet another damn schema to define one’s validation scheme.

Of course, this is without even considering the dubious value of having XML schemas in the first place. They’re hardly ideal for any sort of load as one could have written the trade in blood and hand delivered it in the time it takes to validate a reasonable sized xml document against its schema. So, does anyone have any suggestions for a lightweight runtime schema validator? Something that is under 2mb? Something that isn’t relax-ng (jarfest) or xerces (bloatware)?

This is not even considering the fairly rapidly changing spec. It went from DTD’s, to schemas, 4 major version numbers, erratas, modifications, clarifications, blahblahblah.

So at the end of the day what do you have? Hours spent deliberating over a spec playing hunt the field. You know you want to transmit an optional early termination date, for example, but now that you’ve become a slave to the big fancy spec, instead of sticking it into your well formed yet surprisingly bloat free xml document, you have to trawl through some spec to find the correct way of expressing it. Needless to say, the counterparty might or might not support it, the hard work of having to talk to them and decide on exactly what data they expect and what they’ll flatly refuse still has to be done. If you’re lucky, it’ll have some passing semblace to the schema, most days one isn’t very lucky at all I’m afraid.

Everyone likes to bash EJBs. They’re old, they’re unfashionable, EJB knowledge didn’t help you become a millionaire like everyone said it would. Go to any reasonably fashionable soapbox and you’ll be mocked for using EJBs and called a Sun bumlicker. Well, I use EJBs and happen to like them a lot. However, that is not to say they’re without their fair share of headaches. So I’m going to try and present real problems with the current EJB spec (2.0 and 2.1), vs the usual ‘they suck! they don’t scale! Nobody needs that much power! They don’t allow for obfuscated object models!’ arguments.

Limited EJBQL: I really don’t understand the logic behind this. An abstraction query layer over SQL makes sense, sure, however, why cripple it so horribly? Why not support that cutting edge datatype…Date? I mean, you’d have to look really hard to find any sort of object storage thingy which doesn’t understand dates in some form or another. Why not make it dynamic while you’re at it, and perhaps even allow a backdoor for those pesky legacy system which require obscure handcrafted 10 line long sql queries?

Idiotic object relation constraints: We actually have a good collection of these constraints, so I’ll try to give credit to the top ones. First, O/R has to be between local entities within the same module. Why? Is this yet another case of vendors saying ‘well any other way is too hard for us, lets just screw the users instead’? I understand the need for modules to be complete standalone units. However, it’s perfectly legal to declare that a module has references to another module, so why can’t this be extended to say that this module has relations with beans in this other module? While remote relations would be nice, I can sympathise somewhat with all the extra headache that would involve in the way of distributed transactions and suchlike, so I’m willing to stop being angry about it if they’ll just give me inter-module local relations.

Another fly in the ointment is the lack of primitive collection support in O/R collections (aka dependent objects in early drafts of the EJB 2.0 spec). Sometimes all one needs to make one’s boss happy is a collection of Strings. It’s not related to anything, it’s not normalised, it’s just a collection of strings in some far flung database join table. Why must I go through the heartache of defining a local entity with just two fields if all I want is a collection of strings, ints, or longs? This seems like such an obvious need to me I’m quite surprised that few vendors provide this even as an extension. My quality of life would increase considerably if I could use EJBQL to traverse my container handled primitive collections. I would be a happier person, a person far less likely to rant and rave all the damn time.

Inconsistent naming convention. One would think that the spec would demand that EJB’s adhere to bean property naming conventions. That the standard bean introspector rules apply. One would be rather wrong though. The spec authors, in their infinite wisdom, decided to mostly stick to that, but with a few twists here and there to ensure that vendors who assume the logical ‘bean’ characteristic of ‘enterprise java beans’ are caught with panties round ankles.

I’m a huge fan of EJBs (yes, entities too), but it would be really nice if these small niggles could be addressed by the powers that be. Then I can be truly gleeful about rubbing in EJBs in the faces of all those whiners with their wishy washy ‘ejbs suck’ articles. Assuming also of course that vendors stop released ‘ejb compliant’ products which gleefully implement a very ‘liberal’ interpretation of the spec, or even better, feel they’re too good for the spec altogether (yes JBoss kids, I’m pointing and laughing at you).

Yes folks it’s that time again, the weekly handing out of the village idiot hat ceremony. As expected, Fred Grott didn’t quite manage to hold onto his hat. In fact, his competition was so stiff he wasn’t even in the running this week.

First a clarification or two. Andrew C. Oliver pointed out (author of America’s blog, king of blogging, hahaha, just the title is winceworthy) a bunch of technical reasons refuting my cruel and heartless POI bashing. He acknowledges that having write support means that your performance will be much slower than if it were a read-only API (which is why my API trumps his, performance-wise), which is a fair point that I will concede. He also mentions that the author of jExcelAPI often uses POI as a source reference and steals from it, which is also a fair point, and that providing write support is orders of magnitude more complex than read-only (I agree). Credit to Andy for doing all the hard work there.

I emailed Andy shortly after he pointed out those facts, telling him I will post corrections in the next weekly update. Last night I received his response…sort of. His response consisted of nothing more than a link to a url with a picture of a man with his head placed firmly in his bottom. I am unsure of what to make of this, perhaps it’s a self portrait? Perhaps he was trying to say a thousand words and thought a picture would provide more value for money? Perhaps he was dumbstruck and rather than risk a Grottism, thought a url would be safest. Very bizarre.

Another worthy mention (for entirely different reasons, alas) is Mr Ryan Ackley. Coincidentally I’m sure, another POI committer. Ryan is fond of depositing random irrelevant posts in various places denouncing me and all that I stand for. Perhaps it’s part of the criteria for an apache.org address (or POI committerhood?), you get a sense of humour test at the door, and if one is detected your application is refused until you can modify that personal flaw.

Also disturbing is some guy who pointed out in a comment that he once defecated in his bathtub then proceeded to ingest it. Interesting behaviour and certainly worth pointing out, but somewhat offtopic I feel.

For those who keep insisting that my style is incredibly annoying to read, believe it or not, I agree. I find this style very irritating during reading, sadly for you though it’s very enjoyable to write in, so, well, hard luck.

The funniest responses by far have been on the JBoss TSS thread. I laughed, I cried (tears of laughter), I cackled, and snickered aplenty. I was mildly irritated to see them link to what is pretty much a personal rant against the general feel and attitude of JBoss, specifically WITHOUT any technical merit. Linking to the second JBoss entry would have been marginally more TSSworthy perhaps. I’d like to apologise to Rickard though, he is naive enough to think that a logical rational argument is the appropriate tack to take with JBoss zealots. Still, they taught him a good lesson there, so hopefully he won’t be making that mistake again. Trust me Rickard, the only way to deal with them is to fight fire with fire.

Someone suggested that instead of being a JBoss zealot, I’m wasting my time being a JBoss basher. Fascinating that those are the only possible modes of existence, and that the former is a perfectly sensible and productive use of one’s time. Apparently I also work at either IBM or BEA, because nobody else could possibly have another bad thing to say about JBoss. Notice that once the anti-JBoss people left the discussion, the JBoss folks kept spasming uncontrollably and posting to one another, in a big mutual circlejerk to get back that ‘we’re all in this together and believe in the One True Cause’ feeling they are breastfed from the JBoss Group’s teats.

So it was indeed very difficult picking a winner for this week’s much coveted (apparently) village idiot of the week hat from that illustrious crowd. However, there can be only one, and that one is…Thomas Mattson! Thomas was a late bloomer in the thread. He possibly had some work to do earlier in the day so didn’t manage to get in on the initial rush. However, once he found the thread, he twitched his way into an orgy of posting. First he pointed out that JBoss detractors are clearly jealous (come on folks, the ‘you’re jealous’ tactic went out of fashion in debate circles at least a decade ago). He then proceeds to point out that as long as his app works on JBoss (he clearly doesn’t use anything else), then that is sufficient for him to call it j2ee complaint (both server and app). This is followed by a number of angry threats and proclamations, ranging from never using SwingMQ again (no idea why), to the holiness of JBoss’ release strategy, while visiting Rickard’s inability to produce any code (!!) in the interim. By himself he’s responsible for almost 10% of all posts on that incredibly long (and useless) thread. So Mr Mattson, here’s your crown. Guard it closely while you can!

Over the course of the last few days, I’ve been helping out Chris Miller with a big update to OSCache. Needless to say, I’ve formulated a few less than happy thoughts about the whole thing which I must now expunge forthwith.

I’ve never been a heavy oscache user. In fact, my usage of it has been very limited, and often wrapped around in a lot of custom code, rather far from the default usage/settings. The problem however is that most people completely abuse this library. OSCache users, brace yourselves, I’m about to be rather rude to you…

Idiots! If your project does not run well without OSCache, you should be utterly ashamed of yourself. It shows that you might well have a lovely design that’ll make bloggers everywhere swoon with admiration and want to have your babies, but it also means you don’t know the first thing about optimisation. OSCache simply hides the problem (rather effectively sometimes). Somehow, you forgot to think about the feelings of that poor bastard who hits an uncached page, or that hapless fool who goes to a page which needs to be refreshed. He’s a small lone voice out there, to be sure. He’s also probably somewhat lacking in confidence, and will probably blame his network connection first. Even if he does suspect foul play, he’ll refresh the page and lo and behold, it’s speedy the next time round, so he assumes it was his own fault somehow.

Well folks, the joke is up. The next time you go to a vaguely java related page and you notice huge differences in speed sometimes, it’s because you’re hitting on the ‘real’ page, the one which shows the full ugly truth of the careless disregard for performance that the developer feels. That selfsame developer who casually calls database queries in tight loops in the name of functionality. The one who will lecture you on the finer points of MVC design, the one who scoffs at scriptlets and likes all their code to be in XML, preferably parsed (or executed!) per request (naturally), with as much reflection as possible to impress their friends and family.

All OSCache does in these situations is simply encourage this needless cruelty to users. You’re sacrificing the one for the many. To you, it’s alright if some people die for the greater good, you probably approve of capital punishment even if it has a 50% rate of guilty convictions.

Of course, this is ignoring the fairly disturbing problems with OSCache itself. I personally am horrified that people would run such code on a production system. Does nobody care about scalability or uptime anymore? Clustering? Is everyone writing apps that have a few hundred hits a day on a good day? Here’s a brief rundown of some of the problems in the current ‘production’ release:

This evening I decided to spend some quality time in my local Barnes and Noble. Usually I stick to the history/current affairs/sociology sections, but today, I ventured further afield into the Java section. I thought maybe I’d learn a thing or two, see what kind of nonsense people are writing about, maybe have a giggle or two at the ludicrous things that people deem bookworthy.

Indeed, it did turn out to be quite the gigglefest. Lets discount all the really beginner stuff (java in 21 days, java in a nutshell, beginner java, java 1.2, java for children aged 3-5, java for single moms, etc etc), and have a look at the more specialised offerings.

The most common ’specialised’ book tends to be about Swing. Somehow though, they all assume that the reader is completely new to the subject. No matter what level the book advertises itself as, half the book is always wasted going over the standard Swing components. It’s as if the reader is assumed to be without access to a JDK/javadocs at all, and thus utterly unable to find this stuff anywhere.

Looking onwards, it turns out that this is a rather recurring theme. Almost every single book has, to some degree or another, huge tracts of information that can be gleaned from the most trivial online search/javadoc perusal. Some of the Struts books particularly excel in this space filler technique; often consuming up to 100 pages explaining the statelessness of http, the mystical nature of request/response protocols, and how useful forwards and redirects are, with the obligatory blurb about MVC this and MVC that. Perhaps they all secretly acknowledge that the average Struts developer is a bit less, well, developed than most people, and thus needs a little bit more hand holding. I suppose that does make them well aimed at their target audience, to be fair.

The EJB books also provide much hilarity. I was particularly tickled by a book advertising itself to be all about EJB 2.1. I naively thought to myself ‘Great! Something that’ll explain all the cool new things in a reasonable detail, perhaps even provide good critical analysis’. No such luck. The ‘2.1′ portion of the title turned out to be mostly a marketing gimmick. The OR/QL chapters all were wisely marked with a ‘2.0/2.1′ heading, with little to no 2.1 specific content. There was a little blurb in the back about Timers and web services, but it seemed to be grudgingly tacked on to avoid being sued, rather than any genuine interest in 2.1. Worried that they might alienate the huge swathes of EJB 1.1 developers (a crowd best left to slowly die the painful miserable death they deserve, foolish fashion victims that they are), the book also wisely includes much 1.1 material.

The one book I was actually looking out for was Bitter EJB. I’m vaguely mulling posting an EJB rant, and so wondered if it had anything I should take into consideration before spouting off. Sadly it was conspicious by its absence.

So I’m left wondering, are there any worthwhile Java books out there aimed at developers well versed in the (seemingly black) art of spec/javadoc reading?

I suggest people read Simon Phipps blog entry lamenting the lack of java.net commentary before reading this

Now now Mr Simon Phipps, surely you’re old and wise enough to know that soliciting feedback in such a sanctimonious manner is bound to get you in trouble?

I was probably one of the happiest people to see java.net launched. I thought it’d be a welcome change from the exercise in frustration that is sourceforge. It’d be a large repository of stuff I’m interested in (any java related) with none of the crap (anything non-java related). I thought that with backing from Sun, it’d be possible to do a cvs update without having to try it 10-20 times before it’s serviced.

Lets not forget the blogs! I wasn’t a blogger when the whole thing was launched. However, when I decided that the bile levels were rising dangerously high and that it’s time to find an outlet, the first thing I did was try to sign up on java.net. Now, maybe it’s aimed at far smarter developers than I, because nowhere could I find a link that would let me create my own blog. What a terrible shame. With all the negative feedback that java.net got, I thought it’d be particularly amusing to bash open source and the various other whiny anti-Sun bloggers from the lofty platform of java.net. As it is, I was forced into using this crappy freeroller account (it was the first suggestion I received) that, for all its abysmal quality of service, offers that one vital link to attracting customers; a functional, visible ‘create your own blog’ link.

It’s a terrible shame, as I quite like Simon from his JBoss bashing on tss, but now I’m forced to mock his latest entry and to direct my ire at an individual, which isn’t quite as much fun as harpooning entire projects/products.

Like any self respecting spec bigot, I thought that getting my app to pass the J2EE Reference Implementation verifier is part of my homework. Sun in many ways is like an abusive parent to us all, we hate it for the physical and mental abuse it puts us through, but in the end it is our parent, and we subconciously all want its approval and vie for its love and attention. So out of that sentiment, I wanted to glow with pride at the fact that my bigass j2ee app pleases this finicky bad parent.

I fire up the verifier and with much trepidation point it at my app. I think things are happening…it’s hard to tell because there’s very little feedback beyond a middling CPU load (dual CPU machine). Hmm, theorising that all good things come to those who wait, I dutifully wait, and wait, and wait. The verifier in fact is so astoundingly slow that you can wander off and pen a few reasonable sized rants (on a different machine, of course) and it’d still be humming away. Probably snickering at you behind your back, bastard thing.

Eventually, I do get some feedback. The error reporting, needless to say, is positively JBossesque. Here are some examples:

In fact, it has a very cool feature. InstaSource(tm)! Guaranteed to help developers everywhere with source code to any jsp they wish to learn from. Unfortunately, since the jboss folks love Windows so much, this amazing feature is only available in the windows version for now. I’m sure though that if the demand is high enough, they’ll open it up to other platforms too in due course. Simply append %00 to any jsp and you get the the source code. Very handy in case the person running that jboss site is being selfish and refusing to open up the source.

I hope those of you who call this a security hole know better by now. It’s a jboss special feature, and if you don’t acknowledge it as such, then you’re clearly some combination of the following:

Let us assume that one is suitably armed with JBoss documentation. Of course, I’ll leave the dubious practice of obfuscating information and forcing users to buy docs as an exercise for the reader’s judgement ability. So, we have the docs, we have the latest download, we’re ready to roll. Lets fire up the server! Hmm, the server seems to spew out endless pages (31, actually) of junk before finally proclaiming it’s up and running. This, it turns out, is a recurring theme. The endless spewage of information, relevant or otherwise, to users. Shutting down provides us with an equally amusing 20 pages. Now, I know that huge long complicated sounding messages give one that warm and fuzzy ‘I’m a hacker’ feeling, I remember booting up linux and feeling special just watching the boot messages fly. However, I personally find it unprofessional and irritating in my old age. Especially since some of those messages are of level WARN and are ludicrously easy to miss.

Speaking of warnings, why should a clean server, with no modifications whatsoever, spew out WARN [DeploymentInfo] Not deleting localUrl, it is null or not a copy: file:[name deleted to protect the guilty] messages? How do I fix it? I’m being warned after all, and I’d like to be well behaved enough not to get these warnings. Of course, I don’t feel too guilty since this happens on a virgin server, one as yet unsullied by my code or applications.

Next, let me try to deploy a bigass j2ee application (which works in a number of other app servers, incidentally) into this beast. First step is to set up a datasource. Hmm, this seems to be a rather complicated process. It’s very much a hit and miss affair, and a case of playing hunt-the-xml-file (a game you better like playing as often and for as long as possible or you’re in trouble). Trawling through the docs is also of little to no help. You’d have to somehow figure out that a DataSource is a resource adaptor, and that there are some db samples littered around, so by copying these to various locations you can hope to stumble into an appropriate directory. Consider a bunch of other appservers, I was able to set up a DataSource on Orion, Pramati, Weblogic (various versions since 4.5), JRun, and pretty much ANY other server either by a) editing a short, brief, sweet xml/properties file, usually very well documented, or b) going to some kind of console interface and adding one there, under a clearly labelled ‘add data source’ option.

Nevermind, maybe the configuration pains are worth it. Actually, no, they’re not. There are many other gotchas waiting to happen. In fact, life with jboss is an endless series of gotchas and ‘you idiot, you thought we read specs huh’. Case in point, there is no support for j2ee application clients. They get deployed, but running them seems a Herculean task verging on the impossible. There is waffle about how to use JBoss RMI invokers, but who the hell cares? Appclients exists so one specifically doesn’t have to know useless crap like that. It might provide good masturbatory material to those who like rutting in a pigsty, but the rest of us have work to do. Maybe they DO support running application clients, but if they do, it really is one of the best kept secrets of JBoss. The terms ‘application client’, ‘appclient’, and ‘application-client’ do not exists anywhere in their docs.

Secondly, JBoss does not allow primitive primary keys. I realise the spec is somewhat unclear on this point, but really, if all other vendors manage to support it, why can’t jboss?

How about their EJBQL support? Works fairly well, actually. Unless of course you happen to have some obscure error in your query (weird usage of MEMBER OF, if I remember correctly). In the civilised world (ie, all other appservers), you’re politely informed that your query is invalid. Of course, as an extra favour, you’re also told of where this query is, what it is, and sometimes exactly which bit of the query is undigestable.

Not so with JBoss! Ho Ho Ho! This particular query results in a NullPointerException. The NPE hilariously springs out from some internal JBoss CMR class. The undiscerning reader will of course foolishly assume that their CMR collections are fubar, but nono, it’s just JBoss cute and cuddly way of saying it’s bad EJBQL. No matter, at least the ejb they report the error about helps you narrow it down somewhat. Wrong again! The name of the EJB reported varies actually. Sometimes it’s the previous one processed, sometimes it’s the next one to be processed, the only consistent thing about it is that it isn’t the one which has the actual error. What a tease.

Of course, no mention of JBoss error reporting is complete without a dressing down of their miles of stacktraces. Long stacktraces to me have become synonymous with ugly/slow/bloated architectures. A stacktrace in a way is like a sequence diagram snapshot. You’re able to see the (often tortuous) path that is taken to execute your code. Comparing Orion stacktraces for example with JBoss ones will give you a rough idea of how much faster Orion is (think few orders of magnitude). There’s also the disturbing habit of reporting the same 5 page stacktrace 3 or 4 times. I realise it’s important to ensure the user realises that something just went splat, but honestly, repeating it so many times? It was just one little error, there really is no need to yell so much. It’d be akin to Tolstoy deciding that War and Peace books had to be sold with 3 copies bonded together into a three thousand pagefest, to ensure that people get the point.

JBoss documentation has a special place in one’s heart too. Again, it very much reminds one of children’s writing. Very cute in places, insightful in others, and simply childish elsewhere. I laughed, I cried, I mostly hunted about uselessly for helpful information. The number of reported downloads varies also by document. The website for example claims over 2 million apparently, whereas the admin guide says it’s 100k+/month, with 100 developers worldwide. The clustering guide thinks differently, with 50k+/month, and 1000 developers worldwide. The CMP guide on the other hand is convinced it’s 150k/month downloads. The log4j guide disagrees with everyone, and says it’s 1 million downloads.

Log4j guide? That’s right, you get 29 pages of log4j love. Clearly logging is such an incredibly difficult and time consuming task that it requires 29 pages to fully explain. Nevermind that in the rest of the civilised world, logging just works and can be assumed to be something that one doesn’t have to worry about.

Speaking of logging, one minor irritant is how astounding easy it is to clobber all of JBoss’ logging. Simply try to configure log4j for your application and hey presto, you’ve hijacked the whole appserver’s logging. Guaranteed to impress girls everywhere.

Of course, all this and more could be forgiven if it were the fastest meanest appserver around. It’s certain mean, but to the wrong people, to the users. Speed wise, well, lets just say in all my benchmarking, JBoss consistently turtles along at the bottom, both in terms of throughput and response times. Particularly hilarious is comparing it to Orion, which will probably service your request, start your TX’s, call your EJB’s, render lovely output, and then solve a few of the world’s problems in the time it takes JBoss to figure out exactly who and what it should route your request to.

The only ray of sunshine in this whole mess is that little splinter group off of JBoss. It’s entirely possible that JBoss COULD be a worthwhile product. There’s nothing inheritely impossible in the concept of a functional worthy of respect open source j2ee project. I’d humbly submit that those involved would have far better luck arriving at that holy grail by acknowledging its weaknesses and not trying to milk it as a cashcow/personal deification platform. Oh, and agreeing on exactly how many downloads jboss has.

Reviewing a bunch of currently fashionable JSR’s (specific numbers not mentioned since they’re in community review and I don’t want to get yelled at by mean Sun people), reveals a rather sick fascination with java.util.Enumeration. I might be missing something crucial here, but can someone explain to me why this is? Enumeration is all good and well for java 1.1, but surely as a partner in crime of Vector and Hashtable, it’s tarred with that same ‘oh that’s so 1997′ brush? Why on earth is it still in use? Are expert group members going through a collective midlife crisis?

For example, many J2EE specs have things like public Enumeration getXXXNames(). What is so sacrilegious about public Iterator getXXXNames()? It’s particularly baffling when considering that J2EE specs are expected to run within a JDK 1.2 container, and the last time I checked, the Collections API (with the ubiguitous Iterator) comes for free with said JDK. I realise Enumeration has one method less and so removes the templates to call .remove in it, but really, the javadocs clearly state that having a read-only iterator is a perfectly civilised usage.

I have nothing against JDK 1.1. In fact, I maintain a bunch of IE applets and so have to support it. It’s fun and enjoyable work, because of the restrictions of the environment you’re running in, not to mention that old fashioned tricks like declaring methods final does actually improve performance. All things have their rightful place, and Enumerations, Vectors, and Hashtables are an anachronism that should die from newer specs.

If someone gives a good explanation of why Enumerations are superior to Iterators (good as in manages to convince me, vs good in some more abstract or universal sense), then the winner gets to nominate a product or API of their choice for some bileblog style lovin’. (PS JDK 1.5 and AOP are off limits for now as I haven’t done much work with either for a good mauling).

Today I’m going to go after an incredibly easy big fat target, JBoss! Love it or hate it, JBoss is rubbish either way. In fact, I think that JBoss presents such a huge target, then I might split the rant into two parts. The first one I’ll stick to personal petty attacks and mockery, and the second will attempt to discuss specific technical issues.

Of course, the line might blur a bit somewhat between the two posts. I also reserve the right to mix and match as I please. Also, if you expect any positive conclusions out of this, or that I have helpful advise for the jboss monkeys, then stop reading now. Go to jboss.org and gawp at the pretty colours instead.

Right, let’s get started. First of all, let us examine the JBoss folks themselves. At the top of the list we have Mr Fleury and his immediate family (whoever thought that open source is a meritocracy clearly has a thing or two to learn about putting family first). We have Mrs Fleury in charge of marketing or somesuch ’soft skill’ aspect. We have Mr Fleury the elder providing legal advise from the peanut gallery while posting the odd ‘this is my first ever post’ entry to TSS to defend himself and his. Finally, I suspect the Fleury kids are on the payroll too, since the guady colours on jboss.org are clearly the results of a healthy child’s imagination.

Then we have mattberk and billsmith, who are like the twins of out Matrix Reloaded with some crucial differences. First, they’re horribly ugly (relative to the twins at any rate). Secondly, they likely don’t dress quite as well. Thirdly, they talk way way too much to be cool. I sometimes have bets with friends on how quickly it’d take one of them to spasm out a response on TSS on any jboss thread. Sometimes their spasms get so severe that they post 3 responses to the SAME person in quick succession. Posts against JBoss are to them akin to a big fat red button directly wired to their nervous systems sending a quick surge of high voltage fun. Here’s a tip guys, if you want to be taken seriously as anything but JBoss lackeys, try not chanting the party line quite so vigorously.

Moving on quickly, let’s examine the jboss site. I’m sure they’re eager to show how professional they are, after all a BEA killer has to woo the same clients. You know, the ones who expect some measure of professionalism, who like to think they’re dealing with a serious corporate entity. So what does this competition have to offer? A garishly coloured website! Not only that, but it has pictures! Pictures of a bunch of throughly ugly people, no less. Now, I’m the first to concede that a bunch of computer geeks lose no credit at all by being physically unattractive. It’s par for the course, and irrelevent to their skillset anyway. Having said that, one would also assume they’d have the decency to realise that it’s their work that speaks for them, not their ugly mugshots. I’m sure those BEA customers are lining up to get their hands on those pretty boys eh? The site isn’t without merit though. If you’re ever depressed or feeling horribly bored, just think back to the JBoss 4.0 advertising, guaranteed to have almost anyone rolling on the floor in hysterical laughter. ‘beyond the stratosphere of application development’ indeed. Perhaps it’s their way of subtly hinting ‘we’re going to shoot off into space with our own incredibly non-J2EE ideas’.

We also have the hilarious claim of ‘over X million downloads’. I wonder how that calculation is made. Knowing Fleury and his dubious tactics, I suspect every time anyone starts a download of any version of JBoss, it counts as a download. So if you download 3.2.0, then download 3.2.1 2 days later, it’s a new figure to add! Every new releases brings with it a few thousand new downloads. No wonder they’re keen on release early release often.

Onto their little spat with Sun. Come on folks, being a poster child for a bunch of cheapskates does not mean you must be taken seriously by real companies. If you can’t pay your fees and play with the big boys, don’t lie and fool people into thinking you’re even near that playground. Describing JBoss as a J2EE application server is like describing a bathtub as a bathroom. Sure, you could piss and shit in it and do all sorts of bathroomy things, but you’d be foolish to do so if right next door you had a bathroom with sink and toilets. JBoss’ bathtub to be fair has chairs and tables in it, but the value of such things in a bathtub is dubious at best.

The worst of breed though has to be JBoss fanatics. Granted, fanatics are all scummy and should be crucified like in the old days, but the JBoss ones are scummier than average. Believe it or not jbossites, you did not invent AOP. Nor are you a particularly impressive implementation of it. JBoss’ ‘freeness’ is also a laughable point. JBoss goes out of its way to be unusable without its pitiful (pay) documentation. The documentation, for anyone who hasn’t bought it, it’s quite hilarious too. Descriptors are posted verbatim into the various (usually horribly out of date) guides. I guess it’s good for filling the odd 20 pages here and there eh?

Finally, you TSS sluts need to realise that not everything is about JBoss. Stop trying to drop its name into every damn conversation. It’s the java world equivalent of calling someone a nazi on IRC. The first person who does it automatically loses the argument.

I’ve had a mildly interesting range of comments so far. Most are stupid and ignorant, however some are quite worthy of mention. First of all kudos to Connor MacNeill who managed to not only understand what I’m trying to say, but to also successfully present a rational explanation, so I retract my cussing of clover. All is good and well, it was indeed a usecase I had not considered. Javier Castañón also made some reasonable points about things like ECS, Jetspeed, and various other apache projects being written ‘back in the day’ when people just didn’t know better, as well as pointing out recent work done to improve the performance of POI, which I wasn’t aware of. Fair enough. For the rest of you, perhaps you missed out on the finer points of debating back in high school. Perhaps even you never got to quite finish high school to learn some of these tricky techniques. Fear not, I’ll give you a helping hand to improve your comment posting skill such that you will be considered wise, insightful, and someone who is able to construct coherent sentences.

Firstly, if you want to refute a point that you disagree with, merely stating the exact opposite is NOT considered compelling evidence. If you want to prove me wrong in stating fact A, you fail miserably if all you state is ‘not A’. Yes, I’m looking at you Mr I-have-a-spanish-blog-and-am-an-IDEA-sheep. You’re not winning any points by repeating all my anti-IDEAisms, and then simply negating them or saying no to them (in Spanish or otherwise). A little more effort next time round please.

Secondly, spelling. I cannot stress enough how important this is. Mr Fred Grott is a good example of that schizoid dyslexic child your mother should have warned you about but likely didn’t. He not so much types out comments as spasms uncontrollably in the vicinity of a keyboard and hopes for the best. This my friend will not impress any girls, I assure you. Strangely enough, Mr Grott somehow manages to produce a vaguely coherent blog, suggesting a fairly severe case of Jekyll and Hyde. It’s fine if you misspell the odd word or two; everyone does it. However, to go out of your way to consistently spell badly, sometimes as much as 50% of your words, is just bad manners. Mr Grott, I hereby crown you village idiot, and you get to wear the hat for the rest of the week. Don’t worry though, once I start mauling JBoss I expect some of their apologists will soon claim your crown.

The most fun however comes from the kneejerk reaction crowd. The ‘you couldn’t possibly have used/written/contributed to any open source stuff’ people. Anyone who knows me will probably laugh at that ‘accusation’, so I feel no need to rise to the bait by naming all the patches and code I’ve contributed over the years. The ‘but it’s free’ excuse is pathetic too. So what if it’s free? Should one be grateful for free stuff, no matter how crappy it is? I’d like to think that people aspire to more in their lives. That attitude of just getting stuff because it’s free is so base. There’s too much to life to not be selective and strive for quantity over quality.

For those of you who had positive things to say, well, thanks.

Ahh, the beloved JDC. The fountain of all wisdom, the source of all things java. That most horrific and useless of websites. I miss the old days, when you could go the front page, and actually see what’s new. You even got dates so you don’t need to scratch your head thinking ‘now did I see this two months ago, or did it just show up today?’. Still, times change and things get bigger, fatter, and less usable. Besides, Sun seems to have chosen to live by that old adage, if you can’t beat em, join em. I can’t think of any other reason for the microsoftesque usability of their sites. Here’s a quick hint to all you web ‘developers’, if your users are using search as a way of navigating your site, you’re a failure and are in dire need of a good firing or two.

The JDC, last I checked, stands for ‘Java Developer something or the other’. Either way, one would think that java developers would pass that minimum entrance requirement, that of having a JVM. The website however doesn’t seem to think so, as the hottest download apparently is ‘Java VM’ in first place. Curiously, ‘J2SE 1.4.1 SDK’ merits only the fourth slot. The wisdom of offering these two things as separate downloads to developers must be for reasons too complex for me to fathom. Ignoring of course the issue of pimping JVM’s to so called developers, who presumabely having become developers, no longer feel that downloading a JVM incessantly is necessarily a ‘hot’ activity.

I remember back when that front page used to show useful things, like oh I dunno, new releases perhaps? Early access releases? JCP specs as they turtle their way into disfunctional final drafts? Things that used encourage one to regularly visit the JDC, if only to laugh at the latest follies Sun indulges in.

Instead, we’re now blessed with a static site, where content subtly changes every now and then. Cleverly though, every attempt is made to disguise these changes. Sometimes they’re buried somewhere down the page, sometimes they’re mixed in with some old content. It’s as if Sun is ashamed of admitting they ever do anything new.

The reason I’m reminded of all these past wounds is the latest indignity forced upon me by the JDC. I log in the other day (to cackle at some of the fun items in the bug parade), and lo and behold, I’m told I need to change my username. Now, I’m VERY pleased that I have (well, had) the username ‘hani’. There are many hani’s in the world, believe it or not. They all regularly get the ‘hani’ logins to all public services before me, bastards that they are. The JDC login however was my pride and joy. Anyway, back to the point at hand. I login, only to be rudely told that I need to change my username. Apparently the JDC now requires usernames to be SIX characters long at least. Why oh why in the name of all that is good and wholesome in this life is such a ludicrous arbitrary restriction now imposed? I mean, if it were a financial institude, I can understand it. I work with many such clients and requiring usernames and password that are at least 8 chars, 2 of which have to be non alphanumeric, 3 of which have to be mixed case, and no vowel can follow a consonant is par for the course. The JDC though? That site whose whole POINT is to be easy and friendly to work with, so that we can all go on pimping Sun hardware and API’s? I’m genuinely curious, and would be very grateful if someone could give me a logical reason for imposing such a bizarre restriction.

Of course, this is all ignoring the problems that have plagued the site for the 6 or so years I’ve been using it. For example, as furiously as I click on the ‘automatic login’ checkbox, it never ever feels I’m worth remembering. I’m forced to incessantly login anew. I can’t decide if it has a personal vendetta against me, or whether it exhibits the same snobbish ‘who do you think you are that I’d remember you’ attitude to everyone.

Please, Sun, fix it. Make it not hurt so much. Make it fun again.

Before I dig in, I’d like to point out that I use IDEA 10-12 hours a day. We have a very intimate relationship, but our honeymoon has been over for a while now. We fight a lot, and now and then I say very mean things to it and even wish I could physically abuse it. I realise this makes me a bad person, but part of me feels rather justified in this rage. We met a few years back, when IDEA was going through the EAP for 2.0. I fondly remember emailing Valentin and helping him track down various bugs (all via email), as well as pestering him about various features.

Times move on though, good apps become successful, and mass markets happen. IDEA is very much the victim of its own success. Instead of being driven by the genius of a select few, it is driven by votes of a bunch of complete and utter imbeciles. Don’t believe me? The stats speak for themselves. Let us examine some of the top votes for features