[
https://issues.apache.org/jira/browse/COLLECTIONS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987484#comment-13987484
]
Benedikt Ritter commented on COLLECTIONS-519:
---------------------------------------------
Guys I really don't understand what you're talking about here. Subclassing a
static util class makes no sense at all. Let's revisit the example given above
(I've added a package declaration) :
{code:java}
package com.myapp.utils
public class ListUtils extends org.apache.commons.collections.ListUtils{
public static boolean isEqualList(final Collection list1, final Collection
list2){
//do something
boolean res = org.apache.commons.collections.ListUtils.isEqualList(list1,
list2);
//do something
return res;
}
}
{code}
What is the difference compared to the following:
{code:java}
package com.myapp.utils
public class ListUtils {
public static boolean isEqualList(final Collection list1, final Collection
list2){
//do something
boolean res = org.apache.commons.collections.ListUtils.isEqualList(list1,
list2);
//do something
return res;
}
}
{code}
There is no difference at all! Subclassing simply makes no sense, since you
can't use polymorphism with static methods. So calling
{{org.apache.commons.collections.ListUtils.isEqualList(list1, list2)}} will
still use the commons implementation and not you're custom implementation. To
use you're custom implementation you have to use the fully qualified class name
of your custom class: {{com.myapp.utils.ListUtils.isEqualList(list1, list2)}}.
> 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)