The BileBlog

Common sense and old fashioned know-how have warned us for years about the evils of premature optimisation. The problem is that this rule of thumb is a bit like traffic laws; designed to cater to the lowest common denominator. This law assumes that the average developer is on the wrong side of the moron/competence scale, and so it’s just safer to let this little idiot go about his merry way without obfuscating his code in the name of optimisation.

During the oscache overhaul, Chris Miller and I decided that it’d be rather handy to be able to specify times for cache expiry. Simple stuff, like at every midnight during a weekday. We also had a number of user requests for it, and cron style expressions seemed a natural fit.

I previously had some written some old cron code so I was going to donate that, but I couldn’t find it and Chris decided it might be fun to write it from scratch anyway. We both looked at the Quartz scheduler’s cron code and had that by-now-familiar bleeding eyes syndrome. For fun, we both went ahead and implemented it, and decided that the fastest implementation is what will get checked in (morally, it was a nice fuck you to pair programmers everywhere too). His version beat mine (not by much, thankfully), so his was what we went with. For fun, I decided to compare it to Quartz’s cron parser, just to see how much premature optimisation can help.

I thought it might be an unfair competition, so I imposed an additional handicap; the oscache version would have to calculate a previous fire time as well as parse the expression, whereas the quartz version just had to parse. Lo and behold, the oscache version is at least an order of magnitude faster, and in average to best case expressions, can be up to a hundred times faster.

Looking over the Quartz code makes it very clear why it’s so pitifully slow. For one thing, every expression creates 7 TreeSets, an assorted smattering of StringTokenizers, and a bevy of Calendars/Dates. The code is littered with naive childish ways of doing things, ignoring the most trivial of shortcuts. For example, it uses things like Integer.parseInt(String.valueOf(c)) to convert a char to an int. Perhaps a brief glance at an ASCII table might reveal a rather obvious shortcut, given that a cron number has a small enough range that you don’t need to worry about all the things that parseInt has to.

Surprisingly, the Quartz code is also too verbose, hard to decipher, and astoundingly unclear. For code that is so time critical, it is odd to see such a cavalier attitude towards object creation and type conversions. The oscache version hardly ever uses objects, preferring instead to stick to primitive arrays.

I’m not advocating that you all go out and throw out your Strings, your hosts of Collections, or your cute and cuddly objects. Sometimes though, just sometimes, it pays to know up front what performance characteristics you’re expecting, and how much it matters, compared to all other concerns.

While perusing the latest and greatest pointless opensource releases, I came upon a wonderful little library, Just4log. What this amazing piece of work does is define an ant task, which uses bcel to add a logger.isDebugEnabled() if block around any logger.debug calls (for jakarta-commons logging only, of course).

The problem with this project (ignoring the fact that it uses bcel, the slowest and most bloated bytecode lib around) is that it’s the latest manifestation of a sickness within the java world. This sickness is the incessant drive to address symptoms rather that causes. It’s like little mavens popping up everywhere. Stupidly complex solutions to problems that shouldn’t exist in the first place.

Just4log proclaims that it addresses the case where one has logger.debug("Blahblahblah is now " + someLongTask());. It does this by using bcel to inject in the if statement into your poor abused compiled classes. Now, suddenly the problem is fixed, with the mere addition of some other random library a bunch dependencies (all in all about 1mb of extra gunk). Now, I realise this is a radical idea and considered somewhat innovative these days, but couldn’t the developer writing the debug statement in the first place just THINK for a second? It is really THAT hard to a) Wrap the code in the if block himself, or b) not call expensive methods in debug statements?

Apparently, it is. Just4log proclaims that writing the if statement yourself is a terrible thing, because ‘Logging/comments should definitely not obfuscate the rest of the code (even if considered as integral parts of the code)’. Who would have thought that in this day and age, an if block is considered obfuscation.

Opensource on the whole is good thing, but there really should be some sort of ratings system whereby stupid ideas can be appropriately mocked and derided. People who write such rubbish should end up feeling a vague feeling of shame, not beam with pride at adding to the mound of rubbish. The problem with people publishing such tripe out in the wild is that very few will stop to point out how utterly pointless and stupid a particular project is. Thus the original authors develop inflated egos and go out and wreak further havoc.

Future plans for Just4log include a GUI, a custom classloader (in case you felt that compile time dependency on bcel isn’t as impressive as a runtime one) and I’m sure other pointless shite.

I wonder how long before this project will be accepted into jakarta-commons, perhaps a new subproject, jakarta-commons-logging-commons-contrib-extras.jar needs to be created?

It’s been brewing for a few weeks, but good old Gerald managed to finally do enough in one week to polevault over all other contenders and take the coveted crown.

More on that later. It’s time to apologise, correct, and clarify first. Regardling freeroller, while it is indeed a crappy service, I am actually rather fond of it. Those who have blogs where they can post with impunity clearly do not suffer for their art. Freeroller makes you work for it, you have to really feel passionate enough to fight all the obstacles it hurls your way. When you do manage it in the end, you have a real sense of achievement, quite distinct from whatever nonsense you were trying to post in the first place. Even the ludicrous ' bug is amusing and cute. Roller’s special way of standing out in that retarded yet oh so adorable way. Let’s hope it never gets fixed!

Regarding coding conventions, I think some people missed the fact that I did not pick on religious issues like braces, or tabs vs spaces. These are matters of personal taste, and there is no One True Way (even if my religion happens to preach spaces in favourof tabs, and braces on next line). By all means, stick to corporate standards when it comes to these things. However, if your corporate standards advocate an idiot style that came about just because your lead engineer happens to have grown up using it, then object, and object loudly. Java has a very definite set of published naming conventions, and advocating these beats quietly sticking to an outdated corporate policy that is often excess baggage carried forward from C++ days anyway.

For what it’s worth, I have nothing against Joshua Bloch. He’s a fairly smart chap. However, the JIQ question was more about debating technique. Religiously quoting someone is too biblesque for me. If you agree with the underlying principle that Mr Bloch is advocating, then advocate the principle, not Joshua Bloch. Save your thumping of holy books for other members of your choir.

Back to poor old Gerald. Gerald first offers up some truly hilarious examples of ‘real-world’ Jelly usage with some talk he gave about Python and java. This talk includes such hilarious examples as ‘Creating UIs using Jelly and XUL’. Yes folks, XUL; that Mozilla idea that all of 3 people use. XUL advocates are usually the craziest of the opensource crazies. They’re usually the kind who put up posters of Linus Torvalds on their bathroom walls, and cuddle up with a penguin every night.

This isn’t enough for angry little Gerald, oh no. He next posts a Fred Grott story on the frontpage of javalobby. Fred’s usual ‘I hate Sun and so I won’t play with them cos they hate dyslexic fuckwits’ nonsense, needless to say. Gerald’s post is so obviously flamebait that even the stupider-than-average JavaLobby crowd doesn’t fall for it, and every single comment not by Gerald points out that he’s an idiot, ignorant, stupid, or some combination thereof. It’s truly impressive to be so retarded that even javalobby posters look down on you. Of course, Gerald just won’t take a hint, and 7 of the 16 messages in that thread are by him, flailing about clumsily trying to prove his point.

Gerald also holds the dubious honour of being the only person banned from javadesktop.org. His posts are so inflammatory, ignorant, and unprofessional that he’s been turfed off after multiple warnings and polite requests. He persistently created multiple accounts and threatened, spammed, and begged to be unbanned.

Perhaps most damning of all, Gerald seems to be a huge fan of Fred Grott. Enough said.

However, Carlos E Perez also deserves a worthy mention. Carlos first posts a hilarious ‘oh, it’s the reverse, the higher you score, the smarter you are!’ comment then reveals that his JIQ is 6, the highest score to date. Here’s a tip Carlos, if you have religious beliefs against EJB’s, object oriented methodology, or anything along those lines, have the courage to admit that it’s a personal preference that is often not applicable to everyone else. Couching it in pretentious tedious terms that span endless paragraphs isn’t fooling anyone.

Still, Gerald completely obliterated the competition. Good job Mr Bauer for so consistently undoing any rise in quality that javalobby might suffer from!

Ever wandered what it is that makes a certain developer a Java idiot? While lying in bed at night under the cloak of a deep darkness, are you assailed with fingers of doubt that claw at your little heart, needles with the poison of ‘am I an idiot, really?’

Well, fear no more. I present you here with a number of questions that any self respecting Java developer must answer. Look deep within your soul and answer truthfully. With luck and a dollop of honesty, you might develop some insight into where you stand on that grand old idiocy scale. So let us begin!

The list of questions below is no particular order, nor are question weighted. Here we go…

One of the Jakarta cabal’s tools for world domination is an evil little project know as Jelly, executable XML. This little monster manages to combine an impressive array of stupid ideas into an unholy alliance that no silver bullet or cross can exorcise.

So what is so bad about Jelly? Well, lets start with the basic premise of Executable XML. XML, believe it or not, is a data structure. The whole idea of ‘executing’ xml is an aberration. The format just doesn’t lend itself nicely to all those things we’ve come to love and enjoy about proper executable code. You know, syntactic sugar like abstraction, flow control, type safety, compile time checks, and so on and so forth (the kind that isn’t shoehorned in regardless of peg size).

As if this wasn’t enough, Jelly comes with yet another expression language. Someone please explain to me this EL fetish that seems to be sweeping the java world. I have yet to come across a single non-developer who groks any EL. It’s STILL gibberish to them, it might as well be code. Except that with every new EL, java developers have to learn yet another syntax, yet another ludicrous mapping between variables, methods, and properties.

Really, if you want to do xml transforms, use xslt or some other appropriate 2001 technology. If you’re so desperate to have code in your scripts, use beanshell at least so you’re not forcing everyone to learn yet another stupid EL.

Even funnier is the set of examples and uses of Jelly. You could for example embed Jelly in a java application. This gains you the ability of discarding compile time safety, and the coolness factor of having a script (as a string) in your code dynamically call…your code. Those of you who think you might as well have called the code yourself and done away with jelly are revealing just how unfashionable and unhip you are.

Still, at least jelly has widespread usage and forms an integral part of a number of successful projects. You know, like that werkflow tool, that its own author admits is dead and has no users. Or perhaps that maven tool that almost anyone with two brain cells to rub together will avoid like the plague.

Another hilarious use of Jelly (taken from the tutorial) is a great way for a designer to prototype a UI and avoid the learning curve of Java. Ahahahaha! I’d like to meet these designers, such intellectual giants they must be if they’re comfortable writing stuff like <table model="${tableModel}"/>. How many UI designers understand what a table model is? How many know about classes names, swing MVC and suchlike? If they do know all this, why on earth aren’t they just coding in java?

Still, it’s from Jakarta, it must be worth its virtual weight in gold. Pfft.