Welcome! Please see the About page for a little more info on how this works.

0 votes
in Clojure by

For Sun/Oracle JDKs, and IBM JDK 1.6, we have this:

user=> (.hashCode 9223372039002259457N) 1

For IBM JDKs 1.7 and 1.8, it changed to this (I do not know why):

user=> (.hashCode 9223372039002259457N) 33

This causes a few example-based tests in Clojure to fail when run on those IBM JDK versions. There does not appear to be any bug in Clojure here. Those tests were written with particular constant values that are different, but have equal .hashCode values, to test Clojure's code generated that selects between branches in a case. In particular, these tests in control.clj fail:

`
;; line 386 in Clojure 1.6.0 and 1.7.0-master-SNAPSHOT as of Mar 19 2015:

(is (== (.hashCode 1) (.hashCode 9223372039002259457N)))

;; and later on line 423 in the same file:
(testing "test warn for hash collision"

(should-print-err-message
 #"Performance warning, .*:\d+ - hash collision of some case test constants; if selected, those entries will be tested sequentially..*\r?\n"
 (case 1 1 :long 9223372039002259457N :big 2)))

`

There are other tests in the same file with the same constant 9223372039002259457N that do not fail with IBM JDKs 1.7 and 1.8, but they do not test hash collisions as they were intended to.

Some possibilities for what could be changed:

  1. Pick a different pair of number other than 1 and 9223372039002259457N when running tests on IBM JDKs 1.7 and 1.8, so that the hash values do collide. For example, 33 and 9223372039002259457N.

  2. skip these tests completely when running on IBM JDKs 1.7 and 1.8.

2 Answers

0 votes
by

Comment made by: alexmiller

I think my preference would be to skip these tests for the ibm jdk.

0 votes
by
Reference: https://clojure.atlassian.net/browse/CLJ-1678 (reported by jafingerhut)
...