Some good points. > I would suggest that if we follow the charter, and all of its theoretically >marvellous > principles, then we end up with lots and lots of small jars. > > I further suggest that this leads to either > a) duplicated code because components don't want to depend on other components for >very small > amounts of code > or > b) a complex web of dependencies, maybe even circular ones
Lots of smallish packages is a good thing-- if packages are too large, a redesign is most probably in order. Of course, you can put as many classes into a .jar file as you wish. My vote will always be in favor of a) in a package that should be used by itself, like much of the stuff in Commons. In fact, I think that the rules for implementing utility classes (which includes everything in the Collections project, etc.) should be strongly conducive to creating classes that can be reused singly, with the exception perhaps of an interface or two, or a single abstract superclass. For instance, if a class uses only one string-handling method, the method should be copied to the class and made private. This sort of approach makes code easier to read, reduces chances of things breaking when changes are made in utility classes, allows smaller deployment footprint in most cases, etc. at the slight cost of overall size increase. To say (as has been said) that this approach is not code reuse but simply copying smacks of snobbery and is incorrect. It is a reuse policy that allows version-freeze on small portions of code. Jeff -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
