[
https://issues.apache.org/jira/browse/COLLECTIONS-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16038520#comment-16038520
]
Bruno P. Kinoshita commented on COLLECTIONS-604:
------------------------------------------------
Hi [~jholtkamp],
>Should we design an approach together
+1
> or what is your favourite way of implementing this here?
I liked your arguments for an approach that follows the behaviour in
`StringUtils`.
[~tn], any feedback on this? We might change some JavaDocs, and make it
null-safe in some cases, without breaking binary compatibility, but still
changing the behaviour. I was reading the last updates in the tickets, and I
think we drove the design of many changes in 4.x. So if you have anything in
mind I'd appreciate any feedback before we start changing the code. Later we
may look at other classes to make this behaviour consistent across the whole
[collections] component.
Cheers
Bruno
> More uniform safe-null methods in CollectionUtils
> -------------------------------------------------
>
> Key: COLLECTIONS-604
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-604
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
> Affects Versions: 4.1
> Reporter: Bruno P. Kinoshita
> Assignee: Bruno P. Kinoshita
> Priority: Minor
> Attachments: COLLECTIONS-604.csv
>
>
> Currently, there are 65 public methods in `CollectionUtils`. And 53 without
> the deprecated ones. Out of these, 24 handle `null` arguments. The remaining
> methods throw a `NullPointerException` (NPE) at some part of its code.
> The methods that handle nulls, throw NPE, or return empty columns, boolean
> values, or just doesn't do anything.
> As a user of the API, I would expect a more uniform behaviour across the
> methods of `CollectionUtils`. COLLECTIONS-600 address one of these methods.
> `removeAll` (2x) and `retainAll` (2x) both state that a NPE will be thrown if
> either parameter is `null`. However, they never check if the values are null,
> and instead allow the code to run until a NPE is thrown.
> And the following code shows that `isEmpty` and `isFull` behave differently
> too.
> {code:java}
> Collection<String> c = null;
> System.out.println(CollectionUtils.isEmpty(c)); // return true
> System.out.println(CollectionUtils.isFull(c)); // throws a NPE
> {code}
> If I don't have to worry about `null`s with `#isEmpty`, I would expect the
> same from its related-method `#isFull`.
> What would be a good approach for it? Define a behaviour to all methods? Or
> leave as is, but add more documentation?
> There are a few methods that can easily be updated to check for `null`
> values. Others would require a bit more thinking. An example if the method in
> question for COLLECTIONS-600. It checks equality of collections, and when
> both collections are `null`, it says that they are equals. Google Guava
> [Iterables#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterables.java#L232]
> and
> [Iterators#elementsEqual|https://github.com/google/guava/blob/312aeb938bd35b5b7c8930e19ff5d1ca38e49424/guava/src/com/google/common/collect/Iterators.java#L274]
> do not check for null values, for what it is worth.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
