You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sebb (JIRA)" <ji...@apache.org> on 2012/05/04 23:12:48 UTC

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

Sebb created POOL-220:
-------------------------

             Summary: PoolableObject#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


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

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

Posted by "Mark Thomas (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/POOL-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Resolution: Fixed

I went for the option of clarifying in the Javadoc that the natural ordering was inconsistent with equals(). Just relying on lastReturnTime and identityHashCode for equals() may have caused bugs elsewhere in the code base - the behaviour would certainly be unexpected.
                
> PoolableObject#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
>
> 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

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

Posted by "Sebb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/POOL-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated POOL-220:
----------------------

    Summary: PooledObject#compareTo() is not guaranteed consistent with equals  (was: PoolableObject#compareTo() is not guaranteed consistent with equals)
    
> 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
>
> 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

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

Posted by "Sebb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/POOL-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb reopened POOL-220:
-----------------------


Forgot to mention that the reason I noticed the behaviour was Findbugs reporting that equals was not being overridden.

This will continue to be reported, unless suppressed.

I think we should at least document that the class intentionally uses Object.equals() - i.e. it has not been overlooked. Or we could implement it as such.

                
> PoolableObject#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
>
> 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

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

Posted by "Mark Thomas (JIRA)" <ji...@apache.org>.
     [ 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