Clojure JIRA

[DJSON-1] Reflection warnings

Fri, 14 Oct 2011 13:22:37 -0500

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.

[DJSON-2] Add support for encoding maps and sequences

Wed, 7 Mar 2012 07:59:48 -0600

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)))

[DJSON-4] Please make function write-string public

Sat, 27 Oct 2012 13:12:54 -0500

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})

[DJSON-6] Exception message in string reader says it is an array reader problem

Fri, 18 Jan 2013 08:57:53 -0600

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.

[DJSON-3] Error writing strings with characters outside the BMP

Fri, 9 Mar 2012 19:41:03 -0600

[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.

[DJSON-5] data.json 0.2.0 must provide 0.1.x API compatibility layer

Sat, 27 Oct 2012 13:09:09 -0500

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.

[DJSON-10] data.json does not AOT

Mon, 29 Apr 2013 12:27:51 -0500

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)

[DJSON-7] Write-str outputs invalid JSON when key/value pairs are removed

Tue, 2 Apr 2013 19:05:10 -0500

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}"

[DJSON-8] write-json is documented to write to arg out, but instead writes to out

Tue, 2 Apr 2013 19:06:03 -0500

write-json is documented to write to arg out, but instead writes to *out*

[DJSON-11] Commas still don't work properly in all cases for removed values via value-fn

Fri, 17 May 2013 08:33:47 -0500

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.

[DJSON-9] Always escape U+2028 and U+2029 to be nice to broken JSON parsers

Sun, 28 Apr 2013 21:46:10 -0500

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.