commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COLLECTIONS-519) private constructors in utility classes break existing code
Date Thu, 01 May 2014 13:01:18 GMT

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

Sebb commented on COLLECTIONS-519:
----------------------------------

I still think it would have been better to extend the existing utility class by composition
rather than sub-classing.

1) the sub-class does not prevent access to the underlying static methods. It would be easy
to accidentally invoke the wrong method.

2) If a new method is added to the Collections class, it will be automatically made available
to the derived class. This can cause problems if the derived class happens to have chosen
the same method signature for different functionality.
It can also cause issues if the new method is a sibling to an existing method that is deliberately
hidden in the derived class; the user would then be able to bypass the local class.

Allowing subclassing of utuility classes does make life simpler for the developer, but only
initially.
However, it does not provide safety for the user of the subclass, and I suspect it will cause
additional headaches for the developer in the long term.

I agree with @Dipanjan Laha that this is not a valid use case for extension; so yes the utilty
class should be regarded as final

> private constructors in utility classes break existing code
> -----------------------------------------------------------
>
>                 Key: COLLECTIONS-519
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-519
>             Project: Commons Collections
>          Issue Type: Bug
>    Affects Versions: 4.x
>            Reporter: Radoslav Paskalev
>             Fix For: 4.1
>
>
> Hello,
> In collections version 4.x all utility classes (example ListUtils, MapUtils, PredicateUtils....)
have private constructors. I consider this to be a serious bug, as it breaks any possibility
the classes to be extended by the users.  The javadoc says that constructors are private in
order to prevent class instantiation but this object instantiation is not really problem and
i think it is more important to allow classes to be extended. The possibility to extend utility
classes was one of the major selling points of commons.lang and commons.collections projects.
In the latest commons.lang project the utility classes still have public constructors.
> Best Regards



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message