The Hibernate project has a great page detailing their beliefs about why the project is successful. The focus is on open source, but I think any project could benefit from them.
Most of the reasons will come as no surprise to anyone with more than a passing familiarity with agile development.
I’m starting to wonder if code generation is a very subtle code smell. Something is nagging that I can’t fully express yet. I’m talking specifically about ‘active’ code generation – the stuff that is regenerated every build (and therefore cannot be hand-modified). It seems that rafts of complexity tend to accrete around the edges of the generated code, as behaviour that wants to be inside the generated classes (but can’t) gets deposited just outside the boundaries. This can lead to the accumulation of static utility classes simply to contain the behaviour that ought to be inside the generated code.
How to address this? Wrapping the generated classes inside hand-written decorator style classes is probably the quickest win. Make sure that all the references to the generated code are isolated from the rest of the system, which should help prevent duplication of the utility code by giving it a well defined place to live.
Code generation is a power tool, like a chainsaw. Just as a chainsaw in the hands of an ice-sculptor can be used to produce breathtaking works of art, it could do an unskilled operator like me a nasty injury. Treat power tools with respect, and know when to use them.
Geoff Oliphant has added his blog to java.blogs. Go Geoff!
The Fishbowl: Util is a language smell.
I beg to differ. Classes should never end in Util. Or Utils or Utilities or any synonym thereof for that matter. They always seem to end up as random collections of static methods that know far too much about the internals of the objects they manipulate.
Far better to rationalise your Util classes into concrete objects. The only time a utility class is justified is when working around final core classes like String. Even then, I find that ‘Strings’ is a perfectly good name for the class, rather than StringUtil.
I would always seek to add a wrapper or decorator class that encapsulates a single instance of the thing being worked on, rather than a static function library. Making java look like C is missing the point (and all the benefits) of working in an OO language.
You know you’ve been working too hard when… you spend the first 3 nights of your holiday dreaming about O/R mapping and lazy loading. Urgh.
In other news, its been really sunny here in Whistler, and the skiing has been great. Snow is a bit slushy lower down, but someone told me today that we’re due for some more snow tonight, which should help a bit.
Next week, we’ll be back to our regularly scheduled Java programming.
Read something yesterday about reflection vs. code generation, on the hibernate site.
It basically said that Smalltalkers prefer runtime reflection and C++ developers prefer code-generation. I’m neither (I was a Java developer before I wrote any Smalltalk, and I’ve never seriously coded in C++). But it occurs that while Java’s reflective capabilities are seriously cool, it’s strong typing means that there is always the slight disconnect that comes from having to use casts and instanceof checks (or always return Object and let the client code worry about it). Reflection in Smalltalk must be pretty fun though!
This is why sometimes reflection is the way to go and sometimes code generation is a better fit. Java sits on the fence on this one (as with so much else).
I’ve more to say on the subject of code generation, but I’m off on holiday now, so unless I get the urge and dive into an internet cafe while there, it might have to wait a week or so.
February 17, 2003
Bruce Eckel Thinks Checked Exceptions are BadAnd I think he’s right
Checked exceptions aren’t necessarily bad, they’re just misused. A lot. Part of the problem is that all the documentation on the subject gives the impression that RuntimeExceptions are somehow more serious than checked exceptions, so most developers tend towards writing and throwing checked exceptions. Imagine the reverse: only a situation so serious that the calling code MUST decide what to do about it warrants a checked exception. Checked exceptions force the developer to explicitly deal with them, or declare that they don’t want to deal with them. Either way, a choice must be made. RuntimeExceptions on the other hand can be ignored, and collectively dealt with at some higher level in the application.
Doesn’t that make more sense?
Explicit casts. I wish there was a compiler option that could make it flag these as warnings (or even better, errors). These hateful things sit there like timebombs in your code, just waiting for an opportunity to explode in a shower of ClassCastExceptions. They are at their most potent when buried somewhere in an infrequently used portion of the application, sometimes waiting for days or weeks until an unsuspecting tester (if you’re lucky) or user (if you’re not) stumbles across them.
They’re often not easy to get rid of. The approach I take is to try and extract out all the places something is being cast into a single method, and funnel all the calling code through that. Once that is done it gets easier to see how to remove the cast completely.
Added later: Obviously its impossible to entirely remove casts when dealing with things like collections. The best you can shoot for is exactly one cast per collection access, by wrapping up your collection accessor calls inside more type-specific methods.
This article from Sun (found here) has proved itself useful in solving a wierd problem that bugged me for over an hour earlier this week, whereby everytime I tried to hide some text that a third party component was printing (by making it the same colour as the background – per the vendors docs) it caused a totally unrelated section of the display to vanish as well. I finally fixed it by passing the component a font with zero size, but it turns out that the Graphics object has a handy ‘create’ method for making copies which can be used to isolate components from each other. It would appear that the supplied component made some changes to the Graphics object which were infecting other parts of the display. I love it when a mystery is solved.
One caveat: the ‘destroy’ method mentioned in the article is actually called ‘dispose’. Always write code samples inside an IDE!
Darren Hobbs 
You must be logged in to post a comment.