Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <21686274.1194865850785.JavaMail.jira@brutus>
Date: Mon, 12 Nov 2007 03:10:50 -0800 (PST)
From: "Brian Egge (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (COLLECTIONS-276) *Utils classes should not be
 extensible or able to be instantiated.
In-Reply-To: <22664612.1194817190789.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COLLECTIONS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541740 ] 

Brian Egge commented on COLLECTIONS-276:
----------------------------------------

I don't see any benefit to restricting a users choices.  Your preference might not be to use inheritance, but that shouldn't restrict others.  I find having a MyCompanyUtils class extend *Utils is quite useful.  I might add an additional overload to a method.  In Eclipse, it will show me all of the possible overloads of a method.  If I then choose one in the super class, I may go ahead and accept the auto-correct.  I might decide to add overloads which accept an array instead of a collection, and want to be able to view them side by side with the other static functions.

I have a StringUtils class which extends the commons.lang.StringUtils.  I generally create this in every project, and it grows as I add String related static functions.  

Making a class final might have had a performance improvement in Java 1.0, but in modern JVMs it has no affect.  I think the Open/Closed principle indicates that you should make your classes open for extension if possible.

> *Utils classes should not be extensible or able to be instantiated.
> -------------------------------------------------------------------
>
>                 Key: COLLECTIONS-276
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-276
>             Project: Commons Collections
>          Issue Type: Improvement
>    Affects Versions: Generics
>            Reporter: Stephen Kestle
>            Priority: Minor
>             Fix For: Generics
>
>
> I don't see any good reason why this CollectionUtils (and others) isn't final with a private constructor.  There are no non-static methods, and any extension of them is going to have to call through to the super to avoid compiler warnings.
> e.g. MyCollectionUtils.select() will provoke the warning that "static methods should be called directly" (on CollectionUtils).
> Which would mean
> MyCollectionUtils{
> public static Collection select(){
>     return CollectionUtils.select();
> }
> Which really defeats the purpose.  In Java5, we have static imports now -  these provide more benefit than previous extension did anyhow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.