[
https://issues.apache.org/jira/browse/LUCENE-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626461#comment-13626461
]
Robert Muir commented on LUCENE-4919:
-------------------------------------
The current hashcode seems to correspond with String.hashCode.
I'm not against this change on some theoretical basis, only mentioning that to
me there is no bug (it does exactly what it says it should do), and that
changing it without being thorough will only create bugs since things rely upon
this.
Any patch to change the hashcode needs to update all these additional things,
such as methods in UnicodeUtil, BytesRefHash collision probing, javadocs in
TermToBytesRefAttribute, and anything else that relies upon this: otherwise it
only causes more harm than good.
> IntsRef, BytesRef and CharsRef return incorrect hashcode when filled with 0
> ---------------------------------------------------------------------------
>
> Key: LUCENE-4919
> URL: https://issues.apache.org/jira/browse/LUCENE-4919
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/other
> Affects Versions: 4.2
> Reporter: Renaud Delbru
> Fix For: 4.3
>
> Attachments: LUCENE-4919.patch
>
>
> IntsRef, BytesRef and CharsRef implementation do not follow the java
> Arrays.hashCode implementation, and return incorrect hashcode when filled
> with 0.
> For example, an IntsRef with \{ 0 \} will return the same hashcode than an
> IntsRef with \{ 0, 0 \}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
