The BileBlog

As tawdry as it might be to descend to everyone else’s level and discuss this pathetic piece of writing, where one Mr Graham decides to singlehandedly define hackerdom and those privileged enough to live there (us poor java folks just don’t cut it), I feel there’s just too much there not to give it a good solid harpooning.

First, this loon proclaims that all the great hackers he knows use python or some such nonsense. Well, let me contrast that with my own experience. Every single java guy I know who has advocated python is guaranteed to be middling and the kind of person who is amused by shiny baubles. The ‘greatest hackers’ on MY list happen to be a bunch of java guys, with lispers and erlangers thrown in. No python, no ruby, and definitely, definitely, no perl.

Even more presumptuous are his claims that hackers are some kind of holy being, that must be treated with the utmost caution and be given endless reams of open sores to play with. In his silly makebelieve world, there are no meetings that said hacker has to attend. Said hacker would never use windows voluntarily, and have all sorts of other bizarroworld properties that I suspect all happen to accidentally apply to the author himself and his friends.

He also claims that perl is the most popular language for voluntary open source work. Hmm, what backing does he have for this claim? On freshmeat in fact, where every little turd releases his open source effluent, java is in second place behind C (yes, even narrowing beating out perl). So I in turn will exercise my ‘make a wild claim through determined arm-flailing’ rights, and say that that proves that when hobbyists need to get things done or hack up stuff for fun, they will choose C or java in their spare time.

The whole article is offensive and ridiculous, and typical of the American attitude he so readily derides. That whole ‘me and my friends are great, let me tell the world about how great we are’ bullshit to try and pretend that he matters, or that his life isn’t as worthless as he probably suspects, deep down inside. The feeble ‘it has nothing to do with arrogance’ attempts fool no one. Pauly rather obviously thinks very highly of his hackerdom and its delighful asshat citizenry.

It’s quite one thing to be proud of what you do, and feel that you’re at the top of your game, for some defined value of game. It’s quite another to be an offensive wanker about it and think that you’re some kind of special animal who matters in the grand scheme of things. You have your place, and it’s not more exalted, relevant, profitable, or contributing to the general advancement of humankind than that of a pretty good salesman possibly selling a decent product. Or that of a pretty decent java developer, or a decent graphics designer.

Today I had a chance again to remember and relive my passionate loathing of commons-logging. It’s truly surprising what a bad piece of work it is, and how evil and insidious it actually is.

Setting aside the ludicrousness of having a wrapper for logging, let’s look at more specific reasons and situations where clogging is simply rubbish.

So, one of the stated goals is that it allows you to seemlessly switch to JDK 1.4 logging. Great! Except that if you do, your performance will be slaughtered. All those tales of people gaining huge performance boosts when disabling logging are likely using JDK 1.4 logging with clogging. The reason? It turns out that every single logging call that results in output creates a new Exception object. Yep, every single one. Now, even the most half and dimwitted amongst you likely know how horribly expensive it is to randomly create Exception objects. So really, the only logical explanation I can think of is that the authors of this monstrosity have a vested interest in ensuring that log4j remains a superior alternative, by deliberately hobbling the JDK 1.4 implementation.

One of the nice things I like about log4j is the output. If commons-logging was so concerned with cross logging API usage, would it have killed them to instead waste their time on writing formatters that make sure that your output looks vaguely consistent? Alas no, it’s not the open sores way. Better to allow for infinite pluggability to minimise any actual work the framework twats have to do.

Finally, it’s surprising that nobody has considered how breathtakingly rude it is to enforce a logging framework on others. Say I have two applications, one of which wants to use log4j, and the other wants to use JD1.4. If you’re using clogging, this is a dicey and risky endeavour from the outset. You never know when one is going to clobber the other. Of course, you could be utterly fuckwitted about it, and fix the problem by writing astoundingly shitty classloaders the way JBoss does, simply to allow child apps to hijack parent classes. All because the idiots keep trying to shove down fuckfaced libraries onto their hapless users.

So do yourself a favour, don’t use commons-logging. It’s an utterly pointless wrapper that will bite you in the ass, and just when you’re busy yelping with pain, will proceed to ram a traffic cone in areas best left virginal.

There’s something faintly comical about the total inability of anyone at Atlassian to write a java web app that manages to stay up more than a day or two.

JavaBlogs, has, since its very inception, been a delightful example of the ‘toss it out there, hope for the best, get bored, moved on’ approach that we’ve come to love and admire so. The early days were fraught with proxy errors, hours of downtime, and general unreachability with little to no warning, notice, apology, or explanation.

However, things got better, it all stabilised, I ran out of ammo. Help was forthcoming though in the shape of one Charles Miller, who let go of his last vestiges of sanity when he joined Atlassian. He took it in his head that it’s time to rewrite javablogs. Out with the old, in with the new! Let’s use a new persistence engine! Let’s use new API’s that get the blood pumping and the cvs updates flowing! Let’s bat at a variety of shiny objects dangling in front of us!

So we have javablogs reborn, mostly similar dysfunctional UI, some pointless graphs, and a return to our beloved instability.

The accusing finger of blame, more often than not, waggles in the direction of poor old postgres. Fine, you add your indexes, do a tuning dance, and all is well. Sadly, that seems to have had little effect. Almost daily, javablogs goes down now. The working hours of Atlassian can easily be inferred based on how long javablogs stays down. The average uptime, according to netcraft, is a pathetic 5 days. Particularly hilarious is that now and then, instead of the server simply falling over (proxy error), we get an OGNL error. I’ll avoid making snide remarks over what the actually means, however tempting it may be.

Of course, it’s not just uptime. The UI itself leaves plenty to be desired. To see your list of despised and ignored blogs, you have to click on ‘favourites’. The logout page has a link to ‘login’. Upon clicking on that, you’re given a one liner that says ’scroll down and log in somewhere down there’. The graphs are meaningless, notifications of downtime non-existent, explanations non-forthcoming, and the content is, as ever, disgraceful.

It’s that time of the month again, where the JDJ readers awards are, well, awarded. Clearly, this event is so successful that sys-con has decided to run the awards every few months, just to whip everyone into a frenzy about the whole debacle.

I won’t waste anyone’s time by pointing out what an obscene insult the whole charade is. Instead, I’ll give out my own awards to rival those of JDJ’s. So, on with the show:

Best java book

Since maven seems to have magically hit that 1.0 milestone, it’s time for a brief refresher on why maven is a horrific abomination and anyone using it is in serious need of an ‘undo lobotomy’ operation.

One of the funniest things about the release announcement is the ‘new features’ section. Maveners seem unique in their ability to flout all release conventions and naming schemes, choosing instead to pile on feature after feature through every release candidate. If that weren’t enough, you can always find some hapless turd who forlornly states that his project works with a particular release candidate, but not the following one.

For a project of this size and horrific complexity (anyone using the words elegant, small, tidy, efficient, or robust in the maven team is told to wash his mouth out with soap and to bend over and receive some sort of ‘holy instrument’ for their transgression), the drive to a release must be all about stability and compatibility. You simply cannot just ask your users to open wide while you stick it to them.

Of course, this doesn’t affect maven so much as its users are those spastic children you made fun of in school. They laugh because you’re laughing, merrily oblivious to the fact that they’re the butt of the joke. All maven developers have to do is look excited and suggest that the hapless users bend over because they’re about to have it stuck to them, and the whole crowd will race to see who can bend furthest, and open widest.

The widespread use of jelly is also hilarious, given that its own author has apologised for his gross behaviour in inflicting such a monstrosity on a largely unsuspecting world. What’s funny about this is how disgruntled the maveners are by his proclamation. More than one has expressed anger and frustration at James’ proclamation and said that it shouldn’t have been said, and that jelly (this is stated a lot more feebly) is still great.

That illustrates another shortcoming of the maven freaks: consistent and systematic evasion of the truth in all its forms. Never go back and redo things, always march forward no matter how many times you realise that the road ahead of you is the worst of all worlds.

To be fair, maven developers are pretty much fucked. They’ve lost all respect from the community at large for their obscene behaviour, yet cannot safely extricate themselves because they have legions of spastic drooling fuckwits that will start flailing about angrily if their shiny object were to be tossed aside. Maven, for better or worse, has a community. That it’s a community of dullards and inbreds is irrelevant, it’s still a community that squeals and twitches and clamours for attention.

Nobody will fault you maven guys for sticking to your poison. I can only hope that amongst you there is at least one person with enough sense, decency, and care for mankind to simply walk away and apologise.

For the rest of the world, maven serves as a valuable lesson. It is a worthy experiment illustrating every single thing one should not do when architecting, designing, developing, writing code, running an open source project, or interacting with fellow man.

I’m going to do something different to pretty much everyone else talking about the EJB3 spec draft. I’m actually going to…provide feedback! While it’s fun to say how great and cool it is, and potentially even more fun to wring my hands, make obscene elephant comments, and cry over how it’ll damage my past and future book sales (known as brucetating about), I will choose to actually talk about the spec itself, and the problems with it as it stands.

The first impression one gets is that it’s really, really, a draft. Mistakes abound, it lacks much polish, but all that’s to be expected, and it’s certainly better than to be left in the dark until a more serious offering emerges.

The first traumatising feature is the prevalence of ‘magic’ methods. Want to be able to do a 2.x style ejbRemove method? No problem, just define one! No interface to implement (if you don’t want to), no compile time contract, just a bunch of random magic method names. This isn’t restricted to method names too, you can even have interface names happen magically simply by suffixing Bean, Impl, or EJB to your beans! Of course, if you happen to screw up and mistype a letter or two, that easy unit testability will come in handy. Why allow unit tests when you can enforce them, by ditching all compile time contracts!

Also, is anyone else distraught by the obsessive use of the acronyms POJO/POJI? While it’s understandable that a bunch of open sores asshats enjoy indulging in this fappery, I find it highly upsetting that this ’street lingo’ has made its way into a supposedly professional serious spec. Is it so hard to say JavaBean/Interface? What’s even funnier is that in every case, the POJO/POJI silliness is never used standalone, but always in paranthesis after ‘regular java bean’ and ‘regular interface’ respectively.

One of my biggest pet peeves remains unanswered too, there is no support for collections of dependents. All those millions of times where it’s useful to just have a collection of strings remain ignored and unheeded.

The EntityManager methods are also baffling, to say the least. The create method, bizarrely, is a no-op if the entity’s identity already exists. No duplicate entity exceptions thrown, no boolean return value, nuthin’. Just a simple no-op. There’s also the joys of the ‘merge’ method. The merge method is, from what I can tell, an update that handles disconnected and container-bound entities. Why it isn’t called ‘update’ is so far, rather unclear.

Surprisingly for a J2EE spec, we have that bane-of-specs, the ‘or’ word. Quoting from the spec: ‘transaction commit will fail, or an exception will be thrown’. If there’s one mantra that all expert groups must live by, it’s clarify. You never ever want to use or in that manner. Specs are there to say X MUST do Y, X can NEVER do Z, and so on. Orisms just make you look silly and get you laughed at (just look at the JDO guys).

The spec also has its share of bad examples. One section consistently and persistently (no pun intended) shows examples of public fields. Are we regressing to the horrible old EJB 1.1 days again? They should at least be protected, for the love of god.

Finally, and perhaps the most criminal aspect of the whole thing, is the rampant hardcoding of all things sqly into your source code as annotations. It looks like we’ve come full circle now, with table names, join strategies, column information and the like all firmly embedded in source code. Even more distressing is that nowhere is there mention of being able to override this with descriptors. Basically anyone who understood or utilised the deployer role in a J2EE environment just got shat on from a great height.

I realise that the majority of ‘J2EE’ developers out there are hibernate humping web pillowbiters, writing random intranet apps with 10 users. That’s fine, you all serve a fine purpose and more power to you. However, there are actually people out there who haven’t yet taken the enterprise out of J2EE, so a little more consideration from the expert group towards these people would go a long way in ensuring you attract more than the spastic TSS metoo opensores penis grabbing pondscum.

DISCLAIMER: Please don’t take all this as facts, read the spec yourself, and for the love of god, prove me wrong.

So there we have it. All the secret meetings are over. All the business cards have been furtively slipped into expectant sweaty palms, and we’ve all said our I’ll call you’s and let’s hook ups. The highest concentration of pretentious knowitall gits has finally dispersed whence it came; JavaOne is no more.

What did we learn from it all? Sweet fuck all, it turns out. I’m proud to say that I did not learn a single thing. I went to some BOF’s, I went to some sessions, I laughed and cried, but learn I did not (partially attributed to my astounding laziness and disinterest). It turns out that the point of this dog and pony show is mostly to see other people, a know thine enemy affair.

Still, my java knowledge might be as shallow and simple-minded as ever, but I did take home some very valuable lessons. From those lessons, I have distilled a number of resolutions that I will definitely try to put into effect if I manage to scam my way into JavaOne next year.

I attended the EJB BOF (or tried to) hoping that there might be some interesting or at least somewhat novel questions. Boy was in for a disappointment!

The first sign of trouble came from some turdburglar from Goldman Sachs. This freak’s main complaint was baffling, to say the least. The asshat was annoyed and troubled by the fact that he could go with JDO OR EJB. The choice seemed to upset him, and it apparently made things very expensive and costly for him, because it forced him to waste months evaluating both. It’s at times like these that one is tempted to just despair of the whole java thing. You have all these people complaining endlessly about the lack of choice and how evil monopolies are, yet this pillowbiter comes along and complains that he’s being given a choice, and that expecting him to do his homework and perhaps even fire off a neuron or two in the dusty cobwebs between his hears is and pick a technology is, apparently, far too much to ask for.

I thought that if the questions continues to be of such pitiful quality, I might as well just leave and find the usual merry band of miscreants drinking their sorrows away.

This, apparently, was a sign of things to come. The next question came from none other than JDO zealot Robin Roos. Surprisingly, nobody bothered tell Robin that standing up to ask questions designed to bait and taunt the EJB spec in an EJB BOF is simply bad manners. No matter how pleasantly couched his question is, it’s blatantly obvious that he is NOT asking in a well intentioned I’d-really-like-to-know-about-ejb-because-I’m-curious-and-mean-well sort of way. If I wanted to listen to this sort of tawdry shite I’d just start reading TSS or something. Disgusted, I left and joined the aforementioned merry band of degenerates for a night of rampant underachieving (no details here, since Matt Raible has far too many incriminating pictures).

The whole thing got me thinking, what the fuck is wrong with these JDO and EJB spec people? Is the java world so starved of controversy and excitement that they must pretend that their pathetic little misunderstanding is worthy of a full scale squabble, to be conducted in public in the truly disgraceful manner it has been?

I don’t know if anyone saw it, but some rumpranger on the JDO spec saw fit to post a news item on TSS proclaiming tripe like ‘EJB and JDO group agree to meet during JavaOne!’. What’s particularly funny is that this announcement was NOT meant to be public, and that it turned out to be rather premature. So much so in fact that clearly someone pulled some strings at TSS and got the article deleted altogether (it no longer shows up!).

Now, even pretending that this is news is pathetic and pitiful. Are you EG members so childish that something as trivial as a discussion must be broadcast as breaking news? Are you so starved for attention that you need to try and make your little spat into something of such importance and worth?

Grow up. Meet up in private, decide what on earth you want to do, and stop making such idiots of yourselves in public. If that’s too much to ask for, then just shut up. You’re ruining the image of the JCP for the rest of us, and making it look like it’s composed of nothing but a bunch of petty vindictive biased children whose methods of self-expression do not extend beyond foot stamping and high pitched wailing. You idiots are supposed to be the pinnacle of Java developers. You are the rare few who have the honour of leading and guiding the rest of us. You hand us specs to follow and be bound by for years to come. For fuck’s sake, don’t squander what little respect we have remaining for you. Set an example of adult behaviour, and maintain that apparently elusive tone of professionalism. Become role models for us to respect and admire, instead of nominal leaders that inspire nothing but shame and cringing.