In one of the comments to Alan's Naming Classes Without a ‘Manager’ article, Darren Greaves suggests that Util could be another contender in the list of class names to avoid.
I disagree.
One of the tricky aspects of API design, especially when designing the base APIs for a programming language, is deciding what goes in, and what stays out. Think of a string. There are an enormous number of things you can do with strings, but to put all of those operations on the String class would just be impractical and bloated. So as the designer, you take those operations that you feel would be most generally beneficial, such as finding the length, searching for and extracting substrings, and so on, and leave out the rest.
Some languages, such as Smalltalk, Objective-C, Ruby, Python, Perl, CLOS... Okay, a great many languages allow you to add behaviour to existing classes. So, for example, if your application really needs a method that reverses a string in-place and the language designer has decided that's not necessary for the supplied String class, you can add your method directly to the String class and be done with it.
Some languages, and this is where Java sits, don't let you do this. If you want to extend a class, you have to subclass it. And then you're stuck with whatever the superclass has made visible. And you can't do it with String anyway, because String is final. This is why most projects I work on end up having a StringUtil class, and every project ends up with a DateUtil. There are things we want to do to strings and dates all the time, but there's no way to put those things where they really belong, on the String and Date classes. Which is why having a Util class isn't a code-smell per se, it's a smell in the underlying language.
Thus, ‘Util’ is shorthand for “stuff that belongs somewhere else, but I'm not allowed to put it there, damnit.”.
Of course, Alan also tells me that being able to dynamically add methods to classes is frequently abused, and usually a Bad Thing when writing large systems, but having used both approaches on a small scale, and vastly preferring the more dynamic approach, it's one of those things I'd like to be able to find out for myself, you know?
Update: In a comment, Chris Winters says:
Whenever I get the urge to put something in a 'Util' class, I first look at what the various Jakarta Commons groups have done.
This is incredibly good advice, and worth shouting louder. There's a lot of really useful stuff out there. That said, I recently found myself rather cynically reimplementing something I'd seen in jakarta-commons, because I didn't want to fight any battles over adding another dependent library to the project.
