[
https://issues.apache.org/jira/browse/COLLECTIONS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986581#comment-13986581
]
Daniel Feist commented on COLLECTIONS-519:
------------------------------------------
Sebb, You comments are valid, and in fact java takes this exact same approach
with Collections, Arrays to ensure they cannot be instantiated or extended. I
also agree that composition/delegation is an valid alternative (albeit more
verbose) way of extending these Util classes to achieve the use case described
above.
What I don't like about using this In this particular case, is that it's
completely inconsistent with rest of commons i.e. IOUtils, BooleanUtils etc.
> 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)
