Clojure JIRAhttp://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DJSON+ORDER+BY+status+DESC%2C+priority+DESC
An XML representation of a search requesten-us4.464925-07-2011[DJSON-1] Reflection warningshttp://dev.clojure.org/jira/browse/DJSON-1
data.json<p>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:</p>
<p>Reflection warning, clojure/data/json.clj:36 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:37 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:51 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:53 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:55 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:90 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:91 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:92 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:93 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:94 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:95 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:105 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:106 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:129 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:132 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:140 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:148 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:157 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:160 - call to equiv can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:278 - reference to field<br/>
isArray can't be resolved.<br/>
Reflection warning, clojure/data/json.clj:346 - reference to field<br/>
isArray can't be resolved.</p>DJSON-1Reflection warningsTaskMajorClosedCompletedUnassignedSean CorfieldThu, 28 Jul 2011 19:03:19 -0500Fri, 14 Oct 2011 13:22:37 -0500Fri, 14 Oct 2011 13:22:37 -050000<p>Fixed (for Clojure 1.3.0) in release 0.1.2 </p>Global Rank[DJSON-5] data.json 0.2.0 must provide 0.1.x API compatibility layerhttp://dev.clojure.org/jira/browse/DJSON-5
data.json<p>For libraries that rely on data.json the 0.2 release was a major unexpected breakage. For example, for<br/>
Monger to support 3 JSON serializers (Cheshire, c.d.j 0.1.x, c.d.j 0.2.x) we had to do this:<br/>
<a href="https://github.com/clojurewerkz/support/blob/master/src/clojure/clojurewerkz/support/json.clj">https://github.com/clojurewerkz/support/blob/master/src/clojure/clojurewerkz/support/json.clj</a></p>
<p>This is some of the craziest code I've seen. While writing it, I realized that several changes<br/>
in the c.d.j. API were easy to shim with a backwards-compatibility function. clojure.data.json/json-str<br/>
can be implemented on top of the new function easily, for example.</p>
<p>clojure.data.json demonstrates very questionable library maintenance practices and the 0.2 release<br/>
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.</p>
<p>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<br/>
and deal with unnecessary c.d.j. API changes. Other library maintainers that extend or depend on c.d.j.<br/>
are caught between a rock and a hard place.</p>DJSON-5data.json 0.2.0 must provide 0.1.x API compatibility layerDefectMajorClosedCompletedStuart SierraMichael KlishinWed, 24 Oct 2012 15:58:09 -0500Fri, 10 Jan 2014 11:10:08 -0600Sat, 27 Oct 2012 13:09:09 -050001<p>According to clojuresphere.com, data.json is relied on by 340+ projects: <a href="http://www.clojuresphere.com/org.clojure/data.json">http://www.clojuresphere.com/org.clojure/data.json</a></p><p>Alternative suggestion: Mark the library as "under development/API subject to change" while &lt; v1.0.</p><p>@Tim McCormack: if a project is used by over 300 other projects and has been around for about a year, it is just lame to use excuses like that. It is too late, too many people already<br/>
use c.d.j.</p><p>Old APIs restored, documented as "DEPRECATED", in release 0.2.1.</p><p>Marking old issues as 'closed'</p>Global Rank[DJSON-11] Commas still don't work properly in all cases for removed values via value-fnhttp://dev.clojure.org/jira/browse/DJSON-11
data.json<p>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.</p>
<p>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.</p>DJSON-11Commas still don't work properly in all cases for removed values via value-fnDefectMajorClosedCompletedUnassignedJohn StonehamThu, 16 May 2013 21:21:08 -0500Fri, 10 Jan 2014 11:10:08 -0600Fri, 2 Aug 2013 14:55:39 -050000<p>Doh! Patch djson-11-fix-comma-printing-patch-v1.txt dated May 17 2013 should really fix things, including changing the test to exhibit the problem (before this fix).</p><p><a href="https://github.com/clojure/data.json/commit/4daaa48e41d0dc1d27e3ceb9d64e46967d31f8b8">Patch applied</a>.</p><p>Marking old issues as 'closed'</p>Global RankPatchCode and Test[DJSON-13] clojure.data.json/pprint output might be cut off http://dev.clojure.org/jira/browse/DJSON-13
data.json<p>From a question in irc<span class="error">&#91;1&#93;</span>.</p>
<p>When running a main from AOT'd class which uses clojure.data.json/pprint to print a large structure, the output may be cut off. It looks like clojure.data.json/pprint does not flush the stream when finished. For comparison, clojure.pprint/pprint adds a prn if it ends with a non endline.</p>
<p>&#8211;</p>
<p>Reproduction:</p>
<p>Download attached jsont.tgz.<br/>
tar -jxf jsont.tgz<br/>
cd jsont.tgz<br/>
lein uberjar<br/>
java -jar target/jsont-0.1.0-SNAPSHOT-standalone.jar</p>
<p>Current output:</p>
<p>[0, 1, 2, 3, ... 9599, 96<br/>
(output cut off after 96)</p>
<p>Expected output:</p>
<p><span class="error">&#91;0, 1, 2, 3, ... 9999&#93;</span></p>
<p>&#8211;</p>
<p>Workaround: adding (flush) after (clojure.data.json/pprint ...) calls.</p>
<p><span class="error">&#91;1&#93;</span> <a href="http://clojure-log.n01se.net/date/2013-09-01.html#20:15">http://clojure-log.n01se.net/date/2013-09-01.html#20:15</a><br/>
<span class="error">&#91;2&#93;</span> <a href="https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/pprint_base.clj#L252">https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/pprint_base.clj#L252</a> </p>DJSON-13clojure.data.json/pprint output might be cut off DefectMajorClosedCompletedUnassignedNelson MorrisSun, 1 Sep 2013 20:32:09 -0500Fri, 10 Jan 2014 11:10:08 -0600Fri, 10 Jan 2014 10:43:13 -060000<p><a href="https://github.com/clojure/data.json/commit/867d0050289ab501c62730c624e6a5eca5263012">https://github.com/clojure/data.json/commit/867d0050289ab501c62730c624e6a5eca5263012</a></p><p>Marking old issues as 'closed'</p>Global Rank[DJSON-12] *value-fn* is not applied to contents of a seqhttp://dev.clojure.org/jira/browse/DJSON-12
data.json<p>When the value of a key is any sequential type, <b>value-fn</b> is not being used to translate the component values in the sequence.</p>DJSON-12*value-fn* is not applied to contents of a seqDefectMajorClosedDeclinedStuart SierraMichael NygardThu, 11 Jul 2013 14:21:02 -0500Fri, 10 Jan 2014 11:10:08 -0600Fri, 30 Aug 2013 08:47:07 -050000<p>I cannot reproduce this issue. Do you have an example or test case?</p><p>I just came across the same/similar issue. For example,</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">(json/write-str [ (java.util.Date.) ] :value-fn (fn [k v] (str v)))</pre>
</div></div>
<p>The write-array function does not make use of the <b>value-fn</b> at all, so it defaults to use write-generic instead, which falls through to throw the exception. </p>
<p>Re-using <b>value-fn</b> seems wrong somehow - because it is expecting a key and value perhaps, and in this case there is only ever a value (and there is no concept of a key for sequences).</p><p>The value-fn was not intended to be a general-purpose transformation function, as in Richard Hull's example. It is only for the limited case of transforming selected values with known keys in structured maps, such as:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">(json/write-str [{:date (java.util.Date.)}] :value-fn (fn [k v] (<span class="code-keyword">if</span> (= k :date) (str v) v)))
;;=&gt; <span class="code-quote">"[{\"</span>date\<span class="code-quote">":\"</span>Wed Aug 07 14:13:00 EDT 2013\<span class="code-quote">"}]"</span></pre>
</div></div>
<p>If you want to extend the write functions to new types, you can extend the <a href="https://github.com/clojure/data.json/blob/64f7d311bb5e8a5a6032ad071c675b4c257dc3fc/src/main/clojure/clojure/data/json.clj#L282">JSONWriter protocol</a>.</p>
<p>If you need a general-purpose transformation that walks the entire data structure, you can use <tt>clojure.walk</tt>.</p><p>I have attempted to clarify the docstrings around <tt>:value-fn</tt> in <a href="https://github.com/clojure/data.json/commit/9fac8f19228ba01c695018a9b7ebe174476723a0">commit 9fac8f19</a>.</p><p>Closing this issue for lack of a reproducible test case.</p><p>Marking old issues as 'closed'</p>Global Rank[DJSON-3] Error writing strings with characters outside the BMPhttp://dev.clojure.org/jira/browse/DJSON-3
data.json<p><span class="error">&#91;This ticket filed as a follow on from pull request 2 at github&#93;</span></p>
<p>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.</p>
<p>I have demonstrated the problem in a test, and fixed this: will file a patch when my contributor agreement is in place.</p>Clojure 1.2 and 1.3, Mac OS X, Java 1.6DJSON-3Error writing strings with characters outside the BMPDefectMajorClosedCompletedStuart SierraMatthew PhillipsFri, 16 Dec 2011 17:53:29 -0600Fri, 10 Jan 2014 11:10:09 -0600Wed, 7 Mar 2012 07:58:48 -060012<p>Patch to fix <a href="http://dev.clojure.org/jira/browse/DJSON-3" title="Error writing strings with characters outside the BMP"><del>DJSON-3</del></a>.</p><p>I'm not an expert on JSON, so feel free to correct me if I am wrong, but it seems from reading RFC 4627 that strings in JSON, if they are encoded with the \uxxxx format for hex digits xxxx, should have their 16-bit UTF-16 code units encoded in that way. There should always be exactly 4 hex digits after the \u.</p>
<p>Here are a couple of test cases with the current code, without either of the patches fix_unicode_non_bmp.patch or fix_unicode_non_bmp_2.patch:</p>
<p>user=&gt; (in-ns 'clojure.data.json)<br/>
#&lt;Namespace clojure.data.json&gt;</p>
<p>;; Incorrect.<br/>
clojure.data.json=&gt; (map #(format "%x" (int %)) (json-str "abc\ud834\udd1e" :escape-unicode false))<br/>
("22" "61" "62" "63" "d834" "dd1e" "dd1e" "22")</p>
<p>;; Also incorrect.<br/>
clojure.data.json=&gt; (json-str "abc\ud834\udd1e")<br/>
"\"abc\\u1d11e\\udd1e\""</p>
<p>Here is the behavior with patch fix_unicode_non_bmp.patch:</p>
<p>; This is correct<br/>
clojure.data.json=&gt; (map #(format "%x" (int %)) (json-str "abc\ud834\udd1e" :escape-unicode false))<br/>
("22" "61" "62" "63" "d834" "dd1e" "22")</p>
<p>;; but this is not. JSON specifies that UTF-16 code units should be<br/>
;; included in string in form \uxxxx, for hex encoding xxxx of 16-bit<br/>
;; code units.<br/>
clojure.data.json=&gt; (json-str "abc\ud834\udd1e")<br/>
"\"abc\\u1d11e\""</p>
<p>Here is the behavior with patch fix_unicode_non_bmp_2.patch:</p>
<p>;; correct<br/>
clojure.data.json=&gt; (map #(format "%x" (int %)) (json-str "abc\ud834\udd1e" :escape-unicode false))<br/>
("22" "61" "62" "63" "d834" "dd1e" "22")</p>
<p>;; also correct.<br/>
clojure.data.json=&gt; (json-str "abc\ud834\udd1e")<br/>
"\"abc\\ud834\\udd1e\""</p><p>fix_unicode_non_bmp_3.patch is same as fix_unicode_non_bmp_2.patch, except it includes the unit test Matthew Phillips had in his patch, plus another one to test the :escape-unicode true case.</p><p>Eventually I may even get the hang of this. djson-3-non-bmp-chars-patch.txt contains patch in proper format.</p><p>patch applied.</p><p>Hi Stuart, it looks like you've only applied Andy Fingerhut's last patch. My fix is in the first one: "fix_unicode_non_bmp.patch"</p><p>Matthew, did you see my comment from Jan 12, 2012? I show a test case there that appears not to work with your patch, unless I am misunderstanding the correct JSON desired behavior. That same test does work with my latest patch, I think. Take a look and see what you think.</p><p>Oh I see - I misunderstood what your were doing there, thinking it only applied to the escape-unicode == true case.</p>
<p>And of course the Clojure string is already in UTF-16, so there's no reason to turn it into 32 bit code points and then expand it back to UTF-16 pairs.</p><p>Marking old issues as 'closed'</p>Global RankPatchCode and Test[DJSON-10] data.json does not AOThttp://dev.clojure.org/jira/browse/DJSON-10
data.json<p>When trying to AOT data.json I get the following exception:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">CompilerException java.lang.ClassNotFoundException:
clojure.data.json.JSONWriter, compiling:(clojure/data/json.clj:279:1)</pre>
</div></div>
<p>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.</p>
<p>The exact steps I take to reproduce the bug:</p>
<ul>
<li>fresh checkout of ClojureScript</li>
<li>./script/bootstrap</li>
<li>mkdir classes</li>
<li>./script/repl</li>
<li>(compile 'clojure.data.json)</li>
</ul>
DJSON-10data.json does not AOTDefectMajorClosedDeclinedUnassignedDavid NolenMon, 29 Apr 2013 12:06:14 -0500Fri, 10 Jan 2014 11:10:09 -0600Mon, 29 Apr 2013 12:27:51 -050000<p>Not a bug</p><p>Marking old issues as 'closed'</p>Global Rank[DJSON-17] Double "positive infinity" value leads to json strings that can not be decodedhttp://dev.clojure.org/jira/browse/DJSON-17
data.json<p>If you put a Double/POSITIVE_INFINITY as a value somewhere in your Clojure-collection and convert it to JSON then it will become impossible to decode that JSON back to Clojure-collection. Double/POSITIVE_INFINITY is encoded as "Infinity" string. When you try to parse that JSON, you get an Exception "Exception JSON error (unexpected character): I clojure.data.json/-read".</p>
<p>Can't say whether this really is a bug, but the thing that looks bad is that I couldn't decode what I encoded with the same library, it's not always "x == (read-str (write-str x))".</p>
<p>Here is a simple test to reproduce this behaviour:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">&gt; (require '[clojure.data.json :as json])
nil
&gt; (json/write-str <span class="code-object">Double</span>/POSITIVE_INFINITY)
<span class="code-quote">"Infinity"</span>
&gt; (json/read-str (json/write-str <span class="code-object">Double</span>/POSITIVE_INFINITY))
Exception JSON error (unexpected character): I clojure.data.json/-read (json.clj:226)</pre>
</div></div>
<p>Originally I encountered this problem with clojure.data.json v. 0.1.2:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">(json/read-json (json/json-str <span class="code-object">Double</span>/POSITIVE_INFINITY))
Exception JSON error (unexpected character): I clojure.data.json/read-json-reader (json.clj:158)</pre>
</div></div>JSON library:
<br/>
&lt;dependency&gt;
<br/>
&lt;groupId&gt;org.clojure&lt;/groupId&gt;
<br/>
&lt;artifactId&gt;data.json&lt;/artifactId&gt;
<br/>
&lt;version&gt;0.2.4&lt;/version&gt;
<br/>
&lt;/dependency&gt;
<br/>
<br/>
&lt;dependency&gt;
<br/>
&lt;groupId&gt;org.clojure&lt;/groupId&gt;
<br/>
&lt;artifactId&gt;clojure&lt;/artifactId&gt;
<br/>
&lt;version&gt;1.4.0&lt;/version&gt;
<br/>
&lt;/dependency&gt;DJSON-17Double "positive infinity" value leads to json strings that can not be decodedDefectMajorClosedCompletedStuart SierraAnton LogvinenkoWed, 21 May 2014 17:45:24 -0500Fri, 13 Jun 2014 16:17:48 -0500Fri, 13 Jun 2014 16:17:47 -050001<p>JSON currently does not support any representation of infinity. In <a href="http://tools.ietf.org/html/rfc4627">RFC4627</a>, section 2.4 it reads:</p>
<blockquote><p>Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.</p></blockquote>
<p>A potential workaround would be to decide on a convention whereby <tt>:value-fn</tt> functions passed to <tt>write</tt> and <tt>read</tt> translate <tt>Infinity</tt> to and from a given <tt>String</tt>. However, that's an application specific solution that doesn't really belong in the library. </p><p>Maybe json/write-str should just fail if the collection contains Nan or Infinity? Not sure if this will be the best behavior in all possible use cases, but it would be better in the application where I've encountered it. The server was processing messages from ActiveMQ and silently converting some Doubles to "Infinity" string. If it failed, the server would retry, then log the problem, put messages to DLQ queue and we would know about it. Instead the problem manifested itself only when someone requested the data, plus the stored data was already "corrupted" by the time.</p><p>Fixed on Git master branch as of <a href="https://github.com/clojure/data.json/commit/b4ba1fc056d82b58979759f6c3ca817640c69b23">b4ba1fc0</a>.</p>
<p>Holding release 0.2.5 for possible feedback.</p><p>I've installed local 0.2.5-SNAPSHOT and ran the code. Having NaN inside makes json/write throw an exception "Exception JSON error: cannot write Double NaN clojure.data.json/write-double (json.clj:368)" (similar for Infinity).</p>
<p>On the other hand, json/write with :value-fn works fine and I'm able to replace values I need to.</p>
<p>Seems to me everything works great!</p><p>Released as part of version 0.2.5</p>Global Rank[DJSON-20] data.json reads and writes invalid JSONhttp://dev.clojure.org/jira/browse/DJSON-20
data.json<p>data.json silently reads and writes invalid JSON which pushes error checking out to consumers.</p>
<p><a href="http://www.json.org/">http://www.json.org/</a> states that JSON must be an object or an array composed of values. <a href="http://jsonlint.com/">http://jsonlint.com/</a> follows this pattern.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">&gt; (json/write-str 1)
<span class="code-quote">"1"</span>
&gt; (json/write-str nil)
<span class="code-quote">"<span class="code-keyword">null</span>"</span>
&gt; (json/write-str <span class="code-quote">"charnock"</span>)
<span class="code-quote">"\"</span>charnock\""</pre>
</div></div>
<p>Putting any of the above into <a href="http://jsonlint.com/">http://jsonlint.com/</a> results in an error because jsonlint at least interprets the grammar to necessitate top level values being objects or arrays.</p>
<p>Sadly, Chrome at least seems to do the same thing that data.json is doing here, which I've come to understand as 'non-strict JSON'. I think at the very least, it would be helpful to provide a 'strict' option, as apparently aeson (the Haskell JSON library) does, to pick your poison. I do think it would make sense to default to strict though, as that should be the most widely consumable format, and to then make the choice to drop to non-strict if you're cool with making that contract with all your consumers.</p>
<p>I'm really not sure whether this is a bug or not. Probably more of an enhancement, especially since Chrome at least seems willing to parse each of the above. I'm thinking though of other clients that were written like jsonlint was to assume that JSON is always an object or array at the top level.</p>Clojure 1.6 (et. al. I&#39;m assuming)DJSON-20data.json reads and writes invalid JSONDefectMajorClosedDeclinedStuart SierraTim VisherThu, 14 May 2015 11:28:45 -0500Fri, 19 Jun 2015 14:52:56 -0500Fri, 19 Jun 2015 14:52:51 -050000<p>What are the invalid syntaxes which data.json reads or writes?</p><p>I updated the description with more detail.</p><p>The documentation for the Haskell Aeson library states "the JSON standard requires that the top-level value be either an array or an object."</p>
<p><a href="http://jsonlint.com/">http://jsonlint.com/</a> reports JSON as "invalid" if it does not begin with '{' or '['.</p>
<p>However, I find no evidence for this assertion in <a href="http://json.org/">JSON.org</a> or <a href="http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf">ECMA-404</a>. Neither specifies the valid top-level entry points for a JSON "document." Both define a JSON "value" as any one of string, number, object, array, true, false, or null.</p>
<p><a href="https://tools.ietf.org/html/rfc4627">RFC 4627</a> states "A JSON text is a serialized object or array," but it is superseded by RFC 7159.</p>
<p><a href="https://tools.ietf.org/html/rfc7159">RFC 7159</a> states: "A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array. Implementations that generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts."</p>
<p>Since there may be applications which <b>do</b> consider strings and numbers to be valid JSON texts, it would be an unnecessary limitation on data.json to disallow it.</p>
<p>If you want your application to accept/produce only JSON objects or arrays, such an assertion is trivial to write. Adding a "strict" option to data.json offers little or no value in comparison.</p>Global Rank[DJSON-2] Add support for encoding maps and sequenceshttp://dev.clojure.org/jira/browse/DJSON-2
data.json<p>Here is some trivial workaround code I've been using:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">(defn jsonable [o]
(cond
(map? o)
(zipmap
(keys o)
(map jsonable (vals o)))
(seq? o)
(map jsonable o)))</pre>
</div></div>DJSON-2Add support for encoding maps and sequencesEnhancementMinorClosedDeclinedUnassignedTal LironFri, 7 Oct 2011 14:16:54 -0500Wed, 7 Mar 2012 07:59:48 -0600Wed, 7 Mar 2012 07:59:48 -060000<p>I don't understand. Maps and sequences have always been supported:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">user=&gt; (json-str {:a 1 :b 2})
<span class="code-quote">"{\"</span>a\<span class="code-quote">":1,\"</span>b\<span class="code-quote">":2}"</span>
user=&gt; (json-str (range 5))
<span class="code-quote">"[0,1,2,3,4]"</span></pre>
</div></div>Global Rank[DJSON-4] Please make function write-string public http://dev.clojure.org/jira/browse/DJSON-4
data.json<p>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:</p>
<p>(defn- write-timestamp <span class="error">&#91;Timestamp out&#93;</span><br/>
(write-string (convert-to-iso-time (.getTime Timestamp)) out))</p>
<p>(extend java.sql.Timestamp js/JSONWriter {:-write write-timestamp})</p>DJSON-4Please make function write-string public EnhancementMinorClosedCompletedUnassignedJan HerichenhancementMon, 22 Oct 2012 03:51:18 -0500Sat, 27 Oct 2012 13:12:54 -0500Sat, 27 Oct 2012 13:12:54 -050000<p>Declined. 'write-string' is an implementation detail, not something I will commit to as a public API. Use the :value-fn option of 'write' to handle extension to new types. Or copy the implementation of 'write-string' into your namespace.</p>Global Rank[DJSON-7] Write-str outputs invalid JSON when key/value pairs are removedhttp://dev.clojure.org/jira/browse/DJSON-7
data.json<p>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 ())). </p>
<p>Here is a simple example from the REPL:</p>
<p>main=&gt; (defn remove-nils <span class="error">&#91;k v&#93;</span><br/>
#_=&gt; (if (nil? v)<br/>
#_=&gt; remove-nils<br/>
#_=&gt; v))</p>
<p>main=&gt; (def test<br/>
#_=&gt; {:a nil,<br/>
#_=&gt; :b nil,<br/>
#_=&gt; :c 1,<br/>
#_=&gt; :d nil,<br/>
#_=&gt; :e 2<br/>
#_=&gt; :f nil})</p>
<p>main=&gt; (json/write-str test :value-fn remove-nils)<br/>
;=&gt;"{,\"c\":1,,,\"e\":2,}"</p>
<p>main=&gt; (json/write-str (json/read-str (json/write-str test :value-fn remove-nils)))<br/>
;=&gt;"{\"c\":1,\"e\":2}"</p>clojure.data.json 0.2.0DJSON-7Write-str outputs invalid JSON when key/value pairs are removedDefectMinorClosedCompletedStuart SierraFred CatonTue, 8 Jan 2013 10:05:43 -0600Fri, 10 Jan 2014 11:10:08 -0600Tue, 2 Apr 2013 19:05:10 -050012<p>djson-7-dont-write-unnecessary-commas-v1.txt dated Jan 21 2013 modifies write-object so that it only writes out a comma if :value-fn does not cause the key/value pair to be omitted.</p><p>Patch applied.</p><p>Marking old issues as 'closed'</p>Global RankPatchCode and Test[DJSON-8] write-json is documented to write to arg out, but instead writes to *out*http://dev.clojure.org/jira/browse/DJSON-8
data.json<p>The summary pretty much says it all.</p>DJSON-8write-json is documented to write to arg out, but instead writes to *out*DefectMinorClosedCompletedStuart SierraAndy FingerhutWed, 27 Mar 2013 18:47:50 -0500Fri, 10 Jan 2014 11:10:08 -0600Tue, 2 Apr 2013 19:06:03 -050000<p>Patch djson-8-correct-write-json-patch-v1.txt dated Mar 27 2013 is a simple one-line fix.</p><p>Already fixed in commit d3cce5b200031cf22603c13a9a39e3939651d344</p><p>Marking old issues as 'closed'</p>Global Rank[DJSON-14] read-escaped-char doesn't handle EOF correctlyhttp://dev.clojure.org/jira/browse/DJSON-14
data.json<p>The function read-escaped-char doesn't check the int read from stream for negative values meaning end-of-file. So if you call:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">(json/read-str <span class="code-quote">"\"</span>\\")</pre>
</div></div>
<p>it returns</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">IllegalArgumentException No matching clause: -1 clojure.data.json/read-escaped-<span class="code-object">char</span> (json.clj:122)</pre>
</div></div>DJSON-14read-escaped-char doesn't handle EOF correctlyDefectMinorClosedCompletedUnassignedAlexander KielMon, 28 Oct 2013 04:49:28 -0500Fri, 10 Jan 2014 11:10:08 -0600Fri, 10 Jan 2014 10:12:31 -060000<p>Quick view of patch on github: <a href="https://github.com/alexanderkiel/data.json/compare/djson-14">https://github.com/alexanderkiel/data.json/compare/djson-14</a></p><p>Patch was not in proper `git am` format. Fixed anyway on Git `master`.</p><p>Marking old issues as 'closed'</p>Global RankPatchCode and Test[DJSON-9] Always escape U+2028 and U+2029 to be nice to broken JSON parsershttp://dev.clojure.org/jira/browse/DJSON-9
data.json<p>U+2028 and U+2029 should be treated like \n and, viz, escaped even when &#42;escape-unicode&#42; is false.</p>
<p>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:</p>
<p><a href="http://timelessrepo.com/json-isnt-a-javascript-subset">http://timelessrepo.com/json-isnt-a-javascript-subset</a></p>
<p>While this is broken behavior, it is also quite common, so escaping these characters uniformly may ease some developer pain and surprise.</p>DJSON-9Always escape U+2028 and U+2029 to be nice to broken JSON parsersEnhancementMinorClosedCompletedUnassignedTim McCormackSun, 28 Apr 2013 21:45:46 -0500Fri, 10 Jan 2014 11:10:09 -0600Fri, 2 Aug 2013 15:25:40 -050000<p>Attached patch.</p><p>Reimplemented as an additional optional argument <a href="https://github.com/clojure/data.json/commit/64f7d311bb5e8a5a6032ad071c675b4c257dc3fc">on master</a>.</p><p>Marking old issues as 'closed'</p>Global Rank[DJSON-16] Add positional tracking to JSON readerhttp://dev.clojure.org/jira/browse/DJSON-16
data.json<p>The attached patches add an optional argument to clojure.data.json/read, :track-pos?, that causes the line and column number information for each array and object member to be stored as metadata on the result. Line and column numbers are also added to the various exception messages. Useful for doing validation on a JSON file so that the user can mor easily determine where a problem exists.</p>DJSON-16Add positional tracking to JSON readerEnhancementMinorClosedDeclinedStuart SierraTim ClemonsenhancementerrormsgspatchSun, 18 May 2014 13:52:47 -0500Fri, 6 Jun 2014 15:27:31 -0500Fri, 6 Jun 2014 15:27:31 -050001<p>FYI, it appears my Contributor Agreement has been received and processed: <a href="http://clojure.org/contributing">http://clojure.org/contributing</a></p><p>I'm not opposed to this feature in principle, but I do not want to take the performance hit of this patch: more than 5X slower in my tests, regardless of whether or not you use the feature.</p>Global RankPatchCode and Test[DJSON-19] Add support for Dates, UUIDs, and URIshttp://dev.clojure.org/jira/browse/DJSON-19
data.json<p>I added support for java.util.Date, java.util.UUID, and java.net.URI to json/write-str</p>DJSON-19Add support for Dates, UUIDs, and URIsEnhancementMinorClosedDeclinedStuart SierraMax VeytsmanSun, 22 Feb 2015 23:39:58 -0600Thu, 26 Feb 2015 19:12:26 -0600Thu, 26 Feb 2015 19:12:26 -060000<p><a href="http://json.org/">JSON.org</a> does not define standard encodings for dates, URIs, and UUIDs. Converting these types into strings will need to follow application-specific rules and should be handled in application code.</p>Global RankPatchCode and Test[DJSON-6] Exception message in string reader says it is an array reader problemhttp://dev.clojure.org/jira/browse/DJSON-6
data.json<p>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.</p>DJSON-6Exception message in string reader says it is an array reader problemDefectTrivialClosedCompletedUnassignedStefan KamphausenFri, 14 Dec 2012 05:19:47 -0600Fri, 18 Jan 2013 08:57:53 -0600Fri, 18 Jan 2013 08:57:53 -060000<p>Trivial patch which changes the error message.</p><p><b>incremental</b> patch to add tests for detection of EOF in unterminated arrays and strings. This diff is against HEAD~1, i.e. not against master and thus does not contain the fix itself.</p><p>applied, with slight modifications</p>Global Rank[DJSON-15] A test is written incorrectly so that it tests nothinghttp://dev.clojure.org/jira/browse/DJSON-15
data.json<p>This test has the structure (is (= expr1) expr2), which can never fail, and tests nothing:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">(deftest object-keys-must-be-strings
(is (= <span class="code-quote">"{\"</span>1\<span class="code-quote">":1,\"</span>2\<span class="code-quote">":2"</span>) (json-str (sorted-map 1 1 2 2))))</pre>
</div></div>
<p>Found using a pre-release version of the Eastwood Clojure lint tool.</p>DJSON-15A test is written incorrectly so that it tests nothingDefectTrivialClosedCompletedUnassignedAndy FingerhutMon, 23 Dec 2013 17:40:38 -0600Fri, 10 Jan 2014 11:10:08 -0600Fri, 10 Jan 2014 10:08:09 -060001<p>Patch djson-15-v1.diff corrects the test, including adding a missing } character to the string to compare against.</p><p>Marking old issues as 'closed'</p>Global Rank[DJSON-18] Fast way to print indented jsonhttp://dev.clojure.org/jira/browse/DJSON-18
data.json<p>Hi!</p>
<p>Formatted json is very handy for human consumption, for example, while debugging or exploring JSON API. data.json offers formatting in a form of <tt>pprint-json</tt>. Problem is, <tt>pprint-json</tt> is dead slow because it tries to fit everything within some line width limit. In practice it takes 20-100 times more time to use <tt>pprint-json</tt> instead of <tt>write-str</tt>, up to the point where it just cannot be used in production:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">clojure.data.json=&gt; (def data (read-string (slurp <span class="code-quote">"sample.edn"</span>)))
#'clojure.data.json/data
clojure.data.json=&gt; (count data)
4613
clojure.data.json=&gt; (time (<span class="code-keyword">do</span> (clojure.data.json/write-str data) nil))
<span class="code-quote">"Elapsed time: 219.33 msecs"</span>
clojure.data.json=&gt; (time (<span class="code-keyword">do</span> (with-out-str (clojure.data.json/pprint-json data)) nil))
<span class="code-quote">"Elapsed time: 25271.549 msecs"</span></pre>
</div></div>
<p>Proposed enhancement is very simple: indent new keys and array elements, but do not try to fit values into line width limit. For human, JSON formatted this way is still easy consumable, structure is evident. The only downside is that some lines might become very long.</p>
<p>In a patch attached, I modified <tt>write-array</tt> and <tt>write-object</tt>, added new <tt>:indent</tt> option to <tt>write</tt>. To print indented json, one can write now: <tt>(write-str data :indent true)</tt></p>
<p>There's some performance penalty, of course, but relatively small:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">clojure.data.json=&gt; (time (<span class="code-keyword">do</span> (clojure.data.json/write-str data :indent <span class="code-keyword">true</span>) nil))
<span class="code-quote">"Elapsed time: 250.18 msecs"</span></pre>
</div></div>
<p>I also fixed small bug: <tt>(seq m)</tt> thing in <tt>write-object</tt> should be <tt>(seq x)</tt>.</p>DJSON-18Fast way to print indented jsonEnhancementMajorOpenUnresolvedUnassignedNikita ProkopovMon, 15 Dec 2014 12:18:38 -0600Mon, 15 Dec 2014 12:22:19 -060001Global Rank[DJSON-21] Improper parsing of literalshttp://dev.clojure.org/jira/browse/DJSON-21
data.json<p>Handling of numeric literals doesn't perform according to the JSON spec.</p>
<p>Example:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">(require '[clojure.data.json :as json])
(json/read-str "123abc")</pre>
</div></div>
<p>Returns the number 1232. According to the spec, this should actually be an invalid literal and throw an exception:</p>
<p><img src="http://json.org/number.gif" align="absmiddle" border="0" /></p>DJSON-21Improper parsing of literalsDefectMajorOpenUnresolvedUnassignedMike SukmanowskyTue, 7 Jul 2015 15:24:49 -0500Tue, 28 Jul 2015 17:57:05 -050000<p>(I assume there's a typo in the description - 123 is returned, not 1232)</p>
<p>It's not just literal values, non-whitespace at the end of any input is silently ignored and should be rejected:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">(json/read-str <span class="code-quote">"{}xxx"</span>) =&gt; {}
(json/read-str <span class="code-quote">"[]yyy"</span>) =&gt; []
(json/read-str <span class="code-quote">"\"</span>\<span class="code-quote">"zzz"</span>) =&gt; ""</pre>
</div></div>
<p>NB This behaviour agrees with the docstring ("Reads a single item of JSON data from ...").</p>Global Rank[DJSON-22] Improper parsing of numbers - leading zeroes should be disallowedhttp://dev.clojure.org/jira/browse/DJSON-22
data.json<p>Handling of numeric literals doesn't perform according to the JSON spec.</p>
<p>Example:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">(require '[clojure.data.json :as json])
(json/read-str <span class="code-quote">"0123"</span>)
(json/read-str <span class="code-quote">"{\"</span>num\<span class="code-quote">": 0123}"</span>)</pre>
</div></div>
<p>Both of these examples parse the number as 123. According to the spec, this should actually be an invalid number and throw an exception. NB this restriction does not seem to apply to a number in the exponent, so a number like 1e0003 should be parsed as 1000.0. We handle this case correctly now.</p>DJSON-22Improper parsing of numbers - leading zeroes should be disallowedDefectMajorOpenUnresolvedUnassignedMatthew GilliardTue, 28 Jul 2015 17:51:31 -0500Thu, 30 Jul 2015 10:34:55 -050000<p>Fix + Tests. Feedback welcome.</p>Global Rank