So what the hell is Klactoveesedstene? Actually, I wish I knew (note to self: point of research). It's the name of a Charlie Parker bebop tune, and when trying to come up with a catchy, unique name for this blog, my eyes drifted over the Complete Savoy And Dial Studio Recordings sitting on my desk that I've been meaning to import into my iPod, and it immediately stuck out. That's all.

9:40:45 PM      comment []  trackback []

Funny story at work today about several domain objects in our webapp codebase with extremely verbose toString() methods. You know, you've seen these before:

public class Frob {
    public String toString() {
        StringBuffer buf = new StringBuffer();
        buf.append(getClass().getName()).append(":");
        buf.append("foo=").append(getFoo()).append(",");
        buf.append("bar=").append(getBar()).append(",");
        buf.append("baz=").append(getBaz());
        return buf.toString();
    }
}

Somehow, these toString() methods are supposed to be handy. The next logical step of course is to litter your code with logger statements that dump objects out to the console:

public void doIt(Frob f) {
    logger.fine("Value of frob in doIt: " + f);
}

As it happens, we use a proprietary JDO implementation for persistence in our webapp, which works great most of the time, but in this case the "magic" of bytecode enhancement, transparent persistence, fetch groups and lazy-loading of fields really bit us, because it turned out that there were objects not unlike the above which not only printed out all values of their own fields but all children objects as well. A little while later after iterating through a couple dozen such objects and dumping them out with logger statements, the code had fired some 22,000 select statements at the database in the course of a single web request.

I just may never write another single logging statement or toString() method in my career.

5:29:13 PM      comment []  trackback []