Inconsistent hash with java collections

Description

c.c/hash always use hashCode for java collections, which is incompatible when comparing with Clojure collections, which use Murmur3.

One way to fix it is to add a special case in Util/hasheq for java.util.Collections, as it is now for Strings.

Link to a discussion of this topic in the Clojure group: https://groups.google.com/forum/#!topic/clojure/dQhdwZsyIEw

Environment

1.6.0 master

Attachments

8

Activity

Show:

Alex Miller January 12, 2016 at 4:01 PM

While we are not opposed to addressing this ticket, we are not interested in addressing it at the expense of performance in comparisons that we care about more, and none of the current proposals meets that bar. For now, I am moving this to Backlog but would pull it out if a solution presents itself.

Alex Miller March 16, 2015 at 6:18 PM

afaik, we are still in search of an approach with tolerable performance impacts before this can be considered.

Max Penet March 16, 2015 at 5:22 PM

This bit me again today as well (wasted a lot of time before figuring this one out). Any chance we'll have a patch for 1.7?

Daniel Compton November 13, 2014 at 5:54 AM

This has come up again for me, details are in http://dev.clojure.org/jira/browse/DFRS-7

Daniel Compton November 13, 2014 at 3:19 AM

This hit me when upgrading Factual/skuld from 1.5.1 to 1.6. clojure.data.fressian serialises c.l.PersistentHashSet sets into java.util.HashSet. This breaks equality checking in https://github.com/Factual/skuld/blob/b720feb142e6d274e85be208dc1d6d8634801719/test/skuld/net_test.clj#L8-L29 as we are comparing a set of maps where the original set contains a PersistentSet and the serialised and deserialised one contains a HashSet.

Details

Assignee

Reporter

Approval

Vetted

Patch

Code and Test

Priority

Affects versions

Fix versions

Created March 9, 2014 at 1:48 PM
Updated January 12, 2016 at 4:01 PM