[
https://issues.apache.org/jira/browse/LANG-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-520:
---------------------------------
Fix Version/s: (was: 3.0)
2.5
> HashCodeBuilder.hashCode() should return the same value as
> HashCodeBuilder.toHashCode()
> ---------------------------------------------------------------------------------------
>
> Key: LANG-520
> URL: https://issues.apache.org/jira/browse/LANG-520
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
> Affects Versions: 2.4
> Reporter: Paul Martin
> Priority: Minor
> Fix For: 2.5
>
>
> 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
> LANG-453).
> 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.
