[ https://issues.apache.org/jira/browse/LUCENE-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626475#comment-13626475 ]
Robert Muir commented on LUCENE-4919: ------------------------------------- I have no opinion: I'm not a hashing guy. I'm just mentioning the change is pretty serious. Additionally I'm unhappy the hashcode is part of the API: so I dont think it should be changed in a minor release (e.g. things like TermToBytesRefAttribute expose this as an API requirement). But I think trunk is fine. On the other hand I know the current situation has some bad worst-case behavior that users might actually hit (e.g. indexing increasing numerics), but I don't see sure how this patch addresses that. It seems to me that if we want to go thru all the trouble to improve the hashing (which would be a good thing), we should solve that too, maybe involving a totally different hashing scheme like what they did with java (i dont know). > 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