[ https://issues.apache.org/jira/browse/LUCENE-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626477#comment-13626477 ]
Renaud Delbru commented on LUCENE-4919: --------------------------------------- @Simon: I discovered the issue when using IntsRef. during query processing, I am streaming array of integers using IntsRef. I was relying on the hashCode to compute a unique identifier for the content of a particular IntsRef until I started to see unexpected results in my unit tests. Then I saw that the same behaviour is found in the other *Ref classes. I could live without it and bypass the problem by changing my implementation (and computing myself my own hash code). But I thought this behaviour is not very clear for the user, and could be potentially dangerous, and therefore good to share it with you. > 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