Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 28 Jun 2017 10:06:01 +0000 (UTC)
From: "Jonas Holtkamp (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13075163.1495802518000.123108.1498644361569@Atlassian.JIRA>
In-Reply-To: <JIRA.13075163.1495802518000@Atlassian.JIRA>
References: <JIRA.13075163.1495802518000@Atlassian.JIRA> <JIRA.13075163.1495802518802@jira-lw-us.apache.org>
Subject: [jira] [Commented] (COLLECTIONS-604) More uniform safe-null methods
 in CollectionUtils
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 28 Jun 2017 10:06:14 -0000


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

Jonas Holtkamp commented on COLLECTIONS-604:
--------------------------------------------

[~kinow] No feedback from his side, so I'd start implementing some example cases on the weekend.

> 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.4.14#64029)