[
https://issues.apache.org/jira/browse/JCLOUDS-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15876840#comment-15876840
]
ASF subversion and git services commented on JCLOUDS-1237:
----------------------------------------------------------
Commit b8fd47ba8d0086f3b1b15f43360a1f4c4dd9eff0 in jclouds's branch
refs/heads/master from [~geomacy]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=b8fd47b ]
JCLOUDS-1237: Add compareTo() for IpPermission.
> IpPermission#compareTo is inconsistent with equals
> --------------------------------------------------
>
> Key: JCLOUDS-1237
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1237
> Project: jclouds
> Issue Type: Bug
> Reporter: Sam Corbett
> Priority: Minor
>
> {{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)
