[
https://issues.apache.org/jira/browse/LANG-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781951#action_12781951
]
Jim Sellers commented on LANG-520:
----------------------------------
For anyone else that might need this:
We put into place a master test suite for our projects, and looking at patterns
for bugs is one of the tests.
Here's the java regex that we came up with to find places where people used the
hashCode() instead of the toHashCode() method. It also takes into
consideration where someone calls super.hashCode().
"new\\s+HashCodeBuilder[\\S\\s]+(?<!super\\.)hashCode[^;]+;"
> 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.
