commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita (JIRA)" <>
Subject [jira] [Commented] (COLLECTIONS-604) More uniform safe-null methods in CollectionUtils
Date Tue, 06 Jun 2017 10:06:18 GMT


Bruno P. Kinoshita commented on COLLECTIONS-604:

Hi [~jholtkamp],

>Should we design an approach together


> 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]


> More uniform safe-null methods in CollectionUtils
> -------------------------------------------------
>                 Key: COLLECTIONS-604
>                 URL:
>             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|]
and [Iterators#elementsEqual|]
do not check for null values, for what it is worth.

This message was sent by Atlassian JIRA

View raw message