[jira] [Updated] (JCLOUDS-1237) IpPermission#compareTo is inconsistent with equals

["Ignasi Barrera (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCLOUDS-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ignasi Barrera updated JCLOUDS-1237:
------------------------------------
    Affects Version/s: 2.0.0

> IpPermission#compareTo is inconsistent with equals
> --------------------------------------------------
>
>                 Key: JCLOUDS-1237
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1237
>             Project: jclouds
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>            Reporter: Sam Corbett
>            Priority: Minor
>             Fix For: 2.1.0, 2.0.1
>
>
> {{org.jclouds.net.domain.IpPermission#compareTo}} is inconsistent with its definition of equals. {{compareTo}} only compares protocols whereas {{equals}} compares all fields in the class. The class does not behave in sorted sets.
> From {{Comparable's}} [documentation|https://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html]:
> {quote}
> It is strongly recommended (though not required) that natural orderings be consistent with equals. This is so because sorted sets (and sorted maps) without explicit comparators behave "strangely" when they are used with elements (or keys) whose natural ordering is inconsistent with equals. In particular, such a sorted set (or sorted map) violates the general contract for set (or map), which is defined in terms of the equals method.
> For example, if one adds two keys a and b such that (!a.equals(b) && a.compareTo(b) == 0) to a sorted set that does not use an explicit comparator, the second add operation returns false (and the size of the sorted set does not increase) because a and b are equivalent from the sorted set's perspective.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)