[ https://issues.apache.org/jira/browse/LUCENE-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626450#comment-13626450 ]
Robert Muir commented on LUCENE-4919: ------------------------------------- The hashcode here is not arbitrary, as mentioned in the javadocs: {noformat} /** Calculates the hash code as required by TermsHash during indexing. * <p>It is defined as: * <pre class="prettyprint"> * int hash = 0; * for (int i = offset; i < offset + length; i++) { * hash = 31*hash + bytes[i]; * } * </pre> */ {noformat} There is code in BytesRefHash that relies upon this. > 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