Hi, stumbled on a nasty bug in Clojure. I'm transferring Clojure objects
around using java serialization. When de-serializing a List
(clojure.lang.ASeq) it has a hashCode of 0. This means lookups for the
object in HashMaps PersistentHashMaps HashSets etc fail. The pre-serialized
version of the
I would recommend serializing as strings via pr/read over Java
serialization, but this still sounds like a legitimate bug.
-S
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that
I don't think that's a realistic option for me. I have java objects
embedded in the Clojure forms, and the graph is pretty big.
On Wednesday, October 10, 2012 2:02:45 PM UTC+1, Stuart Sierra wrote:
I would recommend serializing as strings via pr/read over Java
serialization, but this still
I can confirm I am seeing the behavior you describe under Clojure 1.4...
user= (serialize! [1 2 3 4 5] TEST)
nil
user= (.hashCode (deserialize! TEST.ser))
29615266
user= (serialize! [a b c d] TEST2)
nil
user= (.hashCode (deserialize! TEST2.ser))
3910595
user= (serialize! '(a b c d) TEST3)
nil
Lazy-seqs also seem to behave:
user= (serialize! (map inc [1 2 3 4]) TEST4)
nil
user= (.hashCode (deserialize! TEST4.ser))
986115
Jim
On 10/10/12 15:14, Jim foo.bar wrote:
I can confirm I am seeing the behavior you describe under Clojure 1.4...
user= (serialize! [1 2 3 4 5] TEST)
nil
user=
Hmmm...It turns out this is not exclusive to Clojure...
user= (java.util.Collections/unmodifiableList '(1 2 3 4 5))
#UnmodifiableList (1 2 3 4 5)
user= (def l *1)
#'user/l
user= l
#UnmodifiableList (1 2 3 4 5)
user= (serialize! l TEST5)
nil
user= (.hashCode (deserialize! TEST5.ser))
0
Jim
My previous post is not exactly true...From the java docs:
Returns an unmodifiable view of the specified list. ... .Query
operations on the returned list read through to the specified list and
attempts to modify the returned list, whether direct or via its
iterator, result in an
