[
https://issues.apache.org/jira/browse/LANG-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751965#action_12751965
]
Henri Yandell commented on LANG-520:
------------------------------------
Logging is out; Lang doesn't do any logging (yet).
UOE also doesn't feel desirable.
Currently the solutions I see are:
a) hashCode() returns the generated hashcode, not this objects hashcode.
StringBuilder overrides with toString, while EqualsBuilder uses isEquals.
b) Rename method. generateHashCode() for example and deprecate/remove the old
one. Might do the same for the others - generateToString() for example.
c) Document in class doc and method javadocs.
> 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
> 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
> 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.
