You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Mark Thomas (JIRA)" <ji...@apache.org> on 2012/06/17 23:14:43 UTC

[jira] [Resolved] (POOL-220) PooledObject#compareTo() is not guaranteed consistent with equals

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

Mark Thomas resolved POOL-220.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0

Adding the pointless methods was less hassle than setting up a FindBugs exclusion filter and adding it to the build.
                
> PooledObject#compareTo() is not guaranteed consistent with equals
> -----------------------------------------------------------------
>
>                 Key: POOL-220
>                 URL: https://issues.apache.org/jira/browse/POOL-220
>             Project: Commons Pool
>          Issue Type: Bug
>            Reporter: Sebb
>             Fix For: 2.0
>
>
> PooledObject#compareTo only returns 0 if the getLastRuntime values are equal AND the identityHashCodes are equal.
> This will work OK for the identity comparison, but is not guaranteed to work in all other cases.
> It's possible for two distinct objects to have the same identityHashCode. 
> If such objects happen to have the same lastRuntime, then compareTo will return 0, but equals (which defaults to Object#equals) will return false.
> It's not very likely, but it is possible.
> A simple fix would be to define equals() to return true only in the case that the lastRuntime values and identityHashCodes are equal.
> Also, the Javadoc for the compareTo method ought to make clear what the ordering is intended to achieve.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira