From scolebourne@btopenworld.com Sat Aug 2 18:31:41 2003 Return-Path: Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 26477 invoked from network); 2 Aug 2003 18:31:41 -0000 Received: from zinc.btinternet.com (194.73.73.148) by daedalus.apache.org with SMTP; 2 Aug 2003 18:31:41 -0000 Received: from host81-128-69-191.in-addr.btopenworld.com ([81.128.69.191] helo=oemcomputer) by zinc.btinternet.com with smtp (Exim 3.22 #23) id 19j1AP-0007Va-00 for commons-dev@jakarta.apache.org; Sat, 02 Aug 2003 19:31:45 +0100 Message-ID: <004901c35924$728ace60$bf458051@oemcomputer> From: "Stephen Colebourne" To: "Jakarta Commons Developers List" References: Subject: Re: [lang] DEVELOPERS-GUIDE.html Date: Sat, 2 Aug 2003 19:32:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This is a question that we will come back to after the 2.0 release (not wishing to duck the reply....) There may well be alternatives to static utility classes, but I would never expect us to make the ones we have final or private constructor. Stephen ----- Original Message ----- From: "Chuck Daniels" > After reading the thread on [io][vote] FileUtils: decision on style, I can > see where the reasoning comes from for making the "utility" classes > non-final. > > My question then is, is there a better approach to implementing a "utility" > class than by creating a class containing only static methods? That is, can > we implement a "utility" class in such a way that: > > (1) it can be "properly" subclassed if necessary > (2) it can be used with tools such as velocity, and > (3) we don't have to break "good" design rules (such as the arguably "good" > rule that says a "static" class should be made final)? > > I am a purist at heart, as I imagine many others may be, so I wonder if > there is a fundamentally "better" approach that can be taken. Or are we > stuck with a less than elegant compromise due to inherent limitations of the > Java language? > > Thanks again, > Chuck > > > -----Original Message----- > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] > > Sent: Saturday, August 02, 2003 10:07 AM > > To: Jakarta Commons Developers List > > Subject: Re: [lang] DEVELOPERS-GUIDE.html > > > > > > 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" > > > 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:bayard@generationjava.com] > > > > Sent: Thursday, July 31, 2003 9:58 AM > > > > To: Jakarta Commons Developers List > > > > Subject: RE: [lang] DEVELOPERS-GUIDE.html > > > > > > > > > > > > > > > > I've added: > > > > > > > >
  • the class will not be final
    • > > > >
  • methods should generally be 'nice' and 'quiet'. That is, they > > should > > > > suppress Exceptions when sensible.
    • > > > > > > > > as rules for XxxUtils and also: > > > > > > > >

    Exception throwing

    > > > >

    When throwing an exception to indicate a bad argument, always throw > > > > IllegalArgumentException, even if the argument was null. Do not throw > > > > NullPointerException.

    > > > > > > > > > > > > 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: commons-dev-unsubscribe@jakarta.apache.org > > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-dev-help@jakarta.apache.org >