[
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
