commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <>
Subject [jira] [Reopened] (POOL-220) PoolableObject#compareTo() is not guaranteed consistent with equals
Date Sat, 05 May 2012 21:53:48 GMT


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:
>             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
> 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:!default.jspa
For more information on JIRA, see:


View raw message