commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Aymé (JIRA) <>
Subject [jira] Commented: (LANG-520) HashCodeBuilder.hashCode() should return the same value as HashCodeBuilder.toHashCode()
Date Fri, 23 Oct 2009 07:07:59 GMT


Julien Aymé commented on LANG-520:

I think the HashCodeBuilder#hashCode method could be deprecated, so that users miscalling
hashCode instead of toHashCode would have a compilation warning.

(I really don't think that any one would use HashCodeBuilder into an HashMap, or at least
explicitly call hashCode() method).

    public int hashCode() {
        return super.hashCode();

> HashCodeBuilder.hashCode() should return the same value as HashCodeBuilder.toHashCode()
> ---------------------------------------------------------------------------------------
>                 Key: LANG-520
>                 URL:
>             Project: Commons Lang
>          Issue Type: Improvement
>    Affects Versions: 2.4
>            Reporter: Paul Martin
>            Priority: Minor
>             Fix For: 3.0
> HashCodeBuilder's toHashCode() method must currently be used to generate the calculated
hash code value for an object.  However, this method name ('toHashCode') is very similar to
the standard 'hashCode()' method, which will just return the (default) hash code of the HashCodeBuilder
object itself.  Since these names are so similar (and otherwise have the same signature),
they are easy to confuse.  If this happens, then the hashCode used for an object will be that
of the HashCodeBuilder, which then will probably not be compatible with its 'equals' implementation.
 This may result in serious bugs (e.g. memory leaks when combined with ToStringBuilder - see
> I suggest either:
> - Implement HashCodeBuilder.hashCode() to return the same value as .toHashCode() (maybe
with a logged warning), in which case it will not matter if the wrong method is called.  This
will still be compatible with HashCodeBuilder's equals/hashCode contract, since equals is
not implemented, and should therefore be relatively backwards-compatible (though the hashCode
will now change as calls are made to HashCodeBuilder).
> - Throw an UnsupportedOperationException in hashCode().  This is more likely to break
existing code though.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message