The following reflection warnings are reported when using data.json - I was given the impression that "standard" (i.e., new contrib) libraries shouldn't have any:

Reflection warning, clojure/data/json.clj:36 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:37 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:51 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:53 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:55 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:90 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:91 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:92 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:93 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:94 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:95 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:105 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:106 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:129 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:132 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:140 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:148 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:157 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:160 - call to equiv can't be resolved.
Reflection warning, clojure/data/json.clj:278 - reference to field
isArray can't be resolved.
Reflection warning, clojure/data/json.clj:346 - reference to field
isArray can't be resolved.

Here is some trivial workaround code I've been using:

(defn jsonable [o]
	(cond
		(map? o)
			(zipmap
				(keys o)
				(map jsonable (vals o)))
		(seq? o)
			(map jsonable o)))

Please make function write-string in namespace clojure.data.json public, instead of private as it is now: for example, i'm extending java.sql.Timestamp with JSONWriter protocol and i need to send ISO formatted timestamp value as string:

(defn- write-timestamp [Timestamp out]
(write-string (convert-to-iso-time (.getTime Timestamp)) out))

(extend java.sql.Timestamp js/JSONWriter {:-write write-timestamp})

The function read-quoted-string currently uses the same error message as read-array: "JSON error (end-of-file inside array)". Looks like copy and paste error to me. Fix will be trivial IMHO.

[This ticket filed as a follow on from pull request 2 at github]

One of my users decided to start sending Emoji happy faces over a network protocol encoded using data.json, which caused it to promptly roll over and die. It turned out that write-json-string, while aware of the code point vs. character issue, was still iterating over a character count not a code point count.

I have demonstrated the problem in a test, and fixed this: will file a patch when my contributor agreement is in place.

For libraries that rely on data.json the 0.2 release was a major unexpected breakage. For example, for
Monger to support 3 JSON serializers (Cheshire, c.d.j 0.1.x, c.d.j 0.2.x) we had to do this:
https://github.com/clojurewerkz/support/blob/master/src/clojure/clojurewerkz/support/json.clj

This is some of the craziest code I've seen. While writing it, I realized that several changes
in the c.d.j. API were easy to shim with a backwards-compatibility function. clojure.data.json/json-str
can be implemented on top of the new function easily, for example.

clojure.data.json demonstrates very questionable library maintenance practices and the 0.2 release
already cased a lot of confusion and pain to the community. There was 0 communication about the changes upfront, this shows lack of respect to the community and care about backwards compatibility.

So, bringing back a shim API layer for 0.1.x compatibility is a must. There are many codebases on clojure.data.json 0.1.x and their developers probably are not going to stop doing what they are doing
and deal with unnecessary c.d.j. API changes. Other library maintainers that extend or depend on c.d.j.
are caught between a rock and a hard place.

When trying to AOT data.json I get the following exception:

CompilerException java.lang.ClassNotFoundException: 
clojure.data.json.JSONWriter, compiling:(clojure/data/json.clj:279:1)

I encountered this problem while looking into the possibility of AOTing the ClojureScript compiler to avoid startup time issues. ClojureScript now depends on data.json to help with source maps - so this was the first AOT hurdle I encountered.

The exact steps I take to reproduce the bug:

• fresh checkout of ClojureScript
• ./script/bootstrap
• mkdir classes
• ./script/repl
• (compile 'clojure.data.json)

When key/value pairs are removed by the function defined for :value-fn, commas are still output and this results in invalid JSON. To remove the errant commas, I've had to wrap write-str in (write-str (read-str ())).

Here is a simple example from the REPL:

main=> (defn remove-nils [k v]
#_=> (if (nil? v)
#_=> remove-nils
#_=> v))

main=> (def test
#_=> {:a nil,
#_=> :b nil,
#_=> :c 1,
#_=> :d nil,
#_=> :e 2
#_=> :f nil})

main=> (json/write-str test :value-fn remove-nils)
;=>"{,\"c\":1,,,\"e\":2,}"

main=> (json/write-str (json/read-str (json/write-str test :value-fn remove-nils)))
;=>"{\"c\":1,\"e\":2}"

The summary pretty much says it all.

DSON-7 fixes the problem with printing JSON with extra commas, but only as long as the last item is actually printable (the test doesn't appear to demonstrate this, but the keys are iterated in hash order, not insertion order). If the last item's no good, we still have a problem.

The best way to handle this without trying to precalculate value-fn for the next value (in case it's not needed) is to insert the comma BEFORE we print the current value, but only if it's not the first thing to be printed.

U+2028 and U+2029 should be treated like \n and, viz, escaped even when *escape-unicode* is false.

A number of JSON parsers (such as ExtJS's) think they can eval JSON in a JS runtime to decode it. This is not true, since JS does not allow U+2028 and U+2029 unescaped in strings:

http://timelessrepo.com/json-isnt-a-javascript-subset

While this is broken behavior, it is also quite common, so escaping these characters uniformly may ease some developer pain and surprise.