> Craig brings up a really going point...how about if we think about this the
> way that Sun thinks about it with the JDK (god, I can't believe I'm saying
> this)...
>
> The JDK has the java.util package. Within it are Collections classes as well
> as a bunch of other stuff that isn't necessarily related to Collections.
> What if we combine commons-util with commons-collections just like Sun does?
This fits my view of the way to handle utility classes. Generally a
utility class maps directly to a Sun class. It provides some kind of extra
functionality to a standard class or package from Sun. I would match the
Sun naming convention.
So StringUtils would go in: util.lang.StringUtils etc.
In fact, I don't think anything should be in the util package, merely lots
of subpacakages. There's very little in java.util that can't be pushed
into a collections, date or other subpackage.
This enables the scope of the util package to have a nice planned
growth. (?)
Bay
