Your post is welcomed even though I disagree ;-) The choice and decision making process is based on long term watching of [lang] and commons in general. A rule has come about at commons that we should generally allow people to shoot themselves in the foot, rather than restrict them via programmatic means.
This is expressed in - public constructors on utility classes (seems stupid/bad at first, until you realise they are essential for some tools like velocity) - non-final (seems bad too, but is less bad than preventing a user from subclassing) So did we jump the gun? No we merely documented experience and de facto standard. Stephen ----- Original Message ----- From: "Chuck Daniels" <[EMAIL PROTECTED]> > Forgive me if I'm out of line, as this is my first time posting after > following a few threads on this list for some time. > > It seems to me that you have jumped the gun on adding "the class will not be > final" to the document. It doesn't appear to me that any type of consensus > has been reached on the topic of making XxxUtil classes final or not. > > For what it's worth, I vote for making such classes final, as it really > seems to make no sense to subclass classes that contain only static methods. > If you really want to subclass a class, then it should not be a "utility" > class, but perhaps a singleton as Craig suggested earlier in this thread. > > Further, if someone feels that a "utility" class appears to be lacking in > some way, shouldn't they contribute to improving the class rather than > attempting to subclass it without sharing the improvements? > > I also agree with Arun that making a "utility" class non-final does little > more than save you an import statement. > > Cheers, > Chuck > > > -----Original Message----- > > From: Henri Yandell [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 31, 2003 9:58 AM > > To: Jakarta Commons Developers List > > Subject: RE: [lang] DEVELOPERS-GUIDE.html > > > > > > > > I've added: > > > > <li>the class will not be final</li> > > <li>methods should generally be 'nice' and 'quiet'. That is, they should > > suppress Exceptions when sensible. </li> > > > > as rules for XxxUtils and also: > > > > <h4>Exception throwing</h4> > > <p>When throwing an exception to indicate a bad argument, always throw > > IllegalArgumentException, even if the argument was null. Do not throw > > NullPointerException. </p> > > > > > > Is the 'nice' and 'quiet' one okay? Or should I ignore it because there > > are times when XxxUtils might want to throw Exceptions. ie) JdbcUtils > > would throw SQLException from everything and IOUtils should throw > > IOException from everything. > > > > Hen > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
