<< Back to previous view

[DJSON-1] Reflection warnings Created: 28/Jul/11  Updated: 14/Oct/11  Resolved: 14/Oct/11

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Sean Corfield Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Stuart Sierra [ 14/Oct/11 1:22 PM ]

Fixed (for Clojure 1.3.0) in release 0.1.2





[DJSON-5] data.json 0.2.0 must provide 0.1.x API compatibility layer Created: 24/Oct/12  Updated: 10/Jan/14  Resolved: 27/Oct/12

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Michael Klishin Assignee: Stuart Sierra
Resolution: Completed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Michael Klishin [ 24/Oct/12 4:07 PM ]

According to clojuresphere.com, data.json is relied on by 340+ projects: http://www.clojuresphere.com/org.clojure/data.json

Comment by Tim McCormack [ 24/Oct/12 4:11 PM ]

Alternative suggestion: Mark the library as "under development/API subject to change" while < v1.0.

Comment by Michael Klishin [ 24/Oct/12 4:12 PM ]

@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
use c.d.j.

Comment by Stuart Sierra [ 27/Oct/12 1:09 PM ]

Old APIs restored, documented as "DEPRECATED", in release 0.2.1.

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-11] Commas still don't work properly in all cases for removed values via value-fn Created: 16/May/13  Updated: 10/Jan/14  Resolved: 02/Aug/13

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: John Stoneham Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File djson-11-fix-comma-printing-patch-v1.txt    
Patch: Code and Test

 Description   

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.



 Comments   
Comment by Andy Fingerhut [ 17/May/13 8:33 AM ]

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

Comment by Stuart Sierra [ 02/Aug/13 2:55 PM ]

Patch applied.

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-13] clojure.data.json/pprint output might be cut off Created: 01/Sep/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Nelson Morris Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: File jsont.tgz    

 Description   

From a question in irc[1].

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.

Reproduction:

Download attached jsont.tgz.
tar -jxf jsont.tgz
cd jsont.tgz
lein uberjar
java -jar target/jsont-0.1.0-SNAPSHOT-standalone.jar

Current output:

[0, 1, 2, 3, ... 9599, 96
(output cut off after 96)

Expected output:

[0, 1, 2, 3, ... 9999]

Workaround: adding (flush) after (clojure.data.json/pprint ...) calls.

[1] http://clojure-log.n01se.net/date/2013-09-01.html#20:15
[2] https://github.com/clojure/clojure/blob/master/src/clj/clojure/pprint/pprint_base.clj#L252



 Comments   
Comment by Stuart Sierra [ 10/Jan/14 10:43 AM ]

https://github.com/clojure/data.json/commit/867d0050289ab501c62730c624e6a5eca5263012

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-12] *value-fn* is not applied to contents of a seq Created: 11/Jul/13  Updated: 10/Jan/14  Resolved: 30/Aug/13

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Michael Nygard Assignee: Stuart Sierra
Resolution: Declined Votes: 0
Labels: None


 Description   

When the value of a key is any sequential type, value-fn is not being used to translate the component values in the sequence.



 Comments   
Comment by Stuart Sierra [ 02/Aug/13 3:35 PM ]

I cannot reproduce this issue. Do you have an example or test case?

Comment by Richard Hull [ 05/Aug/13 5:13 AM ]

I just came across the same/similar issue. For example,

(json/write-str [ (java.util.Date.) ] :value-fn (fn [k v] (str v)))

The write-array function does not make use of the value-fn at all, so it defaults to use write-generic instead, which falls through to throw the exception.

Re-using value-fn 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).

Comment by Stuart Sierra [ 07/Aug/13 1:39 PM ]

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:

(json/write-str [{:date (java.util.Date.)}] :value-fn (fn [k v] (if (= k :date) (str v) v)))
;;=> "[{\"date\":\"Wed Aug 07 14:13:00 EDT 2013\"}]"

If you want to extend the write functions to new types, you can extend the JSONWriter protocol.

If you need a general-purpose transformation that walks the entire data structure, you can use clojure.walk.

Comment by Stuart Sierra [ 07/Aug/13 1:42 PM ]

I have attempted to clarify the docstrings around :value-fn in commit 9fac8f19.

Comment by Stuart Sierra [ 30/Aug/13 8:47 AM ]

Closing this issue for lack of a reproducible test case.

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-3] Error writing strings with characters outside the BMP Created: 16/Dec/11  Updated: 10/Jan/14  Resolved: 07/Mar/12

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Matthew Phillips Assignee: Stuart Sierra
Resolution: Completed Votes: 1
Labels: None
Environment:

Clojure 1.2 and 1.3, Mac OS X, Java 1.6


Attachments: Text File djson-3-non-bmp-chars-patch.txt     Text File fix_unicode_non_bmp_2.patch     Text File fix_unicode_non_bmp_3.patch     Text File fix_unicode_non_bmp.patch    
Patch: Code and Test

 Description   

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



 Comments   
Comment by Matthew Phillips [ 05/Jan/12 5:57 PM ]

Patch to fix DJSON-3.

Comment by Andy Fingerhut [ 13/Jan/12 1:29 AM ]

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.

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:

user=> (in-ns 'clojure.data.json)
#<Namespace clojure.data.json>

;; Incorrect.
clojure.data.json=> (map #(format "%x" (int %)) (json-str "abc\ud834\udd1e" :escape-unicode false))
("22" "61" "62" "63" "d834" "dd1e" "dd1e" "22")

;; Also incorrect.
clojure.data.json=> (json-str "abc\ud834\udd1e")
"\"abc\\u1d11e\\udd1e\""

Here is the behavior with patch fix_unicode_non_bmp.patch:

; This is correct
clojure.data.json=> (map #(format "%x" (int %)) (json-str "abc\ud834\udd1e" :escape-unicode false))
("22" "61" "62" "63" "d834" "dd1e" "22")

;; but this is not. JSON specifies that UTF-16 code units should be
;; included in string in form \uxxxx, for hex encoding xxxx of 16-bit
;; code units.
clojure.data.json=> (json-str "abc\ud834\udd1e")
"\"abc\\u1d11e\""

Here is the behavior with patch fix_unicode_non_bmp_2.patch:

;; correct
clojure.data.json=> (map #(format "%x" (int %)) (json-str "abc\ud834\udd1e" :escape-unicode false))
("22" "61" "62" "63" "d834" "dd1e" "22")

;; also correct.
clojure.data.json=> (json-str "abc\ud834\udd1e")
"\"abc\\ud834\\udd1e\""

Comment by Andy Fingerhut [ 13/Jan/12 3:18 PM ]

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.

Comment by Andy Fingerhut [ 20/Feb/12 4:03 PM ]

Eventually I may even get the hang of this. djson-3-non-bmp-chars-patch.txt contains patch in proper format.

Comment by Stuart Sierra [ 07/Mar/12 7:58 AM ]

patch applied.

Comment by Matthew Phillips [ 08/Mar/12 6:39 PM ]

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"

Comment by Andy Fingerhut [ 09/Mar/12 11:04 AM ]

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.

Comment by Matthew Phillips [ 09/Mar/12 7:41 PM ]

Oh I see - I misunderstood what your were doing there, thinking it only applied to the escape-unicode == true case.

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.

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-10] data.json does not AOT Created: 29/Apr/13  Updated: 10/Jan/14  Resolved: 29/Apr/13

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

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)


 Comments   
Comment by David Nolen [ 29/Apr/13 12:27 PM ]

Not a bug

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-17] Double "positive infinity" value leads to json strings that can not be decoded Created: 21/May/14  Updated: 13/Jun/14  Resolved: 13/Jun/14

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Anton Logvinenko Assignee: Stuart Sierra
Resolution: Completed Votes: 0
Labels: None
Environment:

JSON library:
<dependency>
<groupId>org.clojure</groupId>
<artifactId>data.json</artifactId>
<version>0.2.4</version>
</dependency>

<dependency>
<groupId>org.clojure</groupId>
<artifactId>clojure</artifactId>
<version>1.4.0</version>
</dependency>



 Description   

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

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

Here is a simple test to reproduce this behaviour:

> (require '[clojure.data.json :as json])
nil
> (json/write-str Double/POSITIVE_INFINITY)
"Infinity"
> (json/read-str (json/write-str Double/POSITIVE_INFINITY))
Exception JSON error (unexpected character): I  clojure.data.json/-read (json.clj:226)

Originally I encountered this problem with clojure.data.json v. 0.1.2:

(json/read-json (json/json-str Double/POSITIVE_INFINITY))
Exception JSON error (unexpected character): I  clojure.data.json/read-json-reader (json.clj:158)


 Comments   
Comment by Tim Clemons [ 22/May/14 7:29 PM ]

JSON currently does not support any representation of infinity. In RFC4627, section 2.4 it reads:

Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.

A potential workaround would be to decide on a convention whereby :value-fn functions passed to write and read translate Infinity to and from a given String. However, that's an application specific solution that doesn't really belong in the library.

Comment by Anton Logvinenko [ 23/May/14 6:13 AM ]

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.

Comment by Stuart Sierra [ 06/Jun/14 4:04 PM ]

Fixed on Git master branch as of b4ba1fc0.

Holding release 0.2.5 for possible feedback.

Comment by Anton Logvinenko [ 07/Jun/14 4:26 PM ]

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

On the other hand, json/write with :value-fn works fine and I'm able to replace values I need to.

Seems to me everything works great!

Comment by Stuart Sierra [ 13/Jun/14 4:17 PM ]

Released as part of version 0.2.5





[DJSON-2] Add support for encoding maps and sequences Created: 07/Oct/11  Updated: 07/Mar/12  Resolved: 07/Mar/12

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Tal Liron Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

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


 Comments   
Comment by Stuart Sierra [ 14/Oct/11 8:38 AM ]

I don't understand. Maps and sequences have always been supported:

user=> (json-str {:a 1 :b 2})
"{\"a\":1,\"b\":2}"
user=> (json-str (range 5))
"[0,1,2,3,4]"




[DJSON-4] Please make function write-string public Created: 22/Oct/12  Updated: 27/Oct/12  Resolved: 27/Oct/12

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Jan Herich Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: enhancement


 Description   

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



 Comments   
Comment by Stuart Sierra [ 27/Oct/12 1:12 PM ]

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.





[DJSON-7] Write-str outputs invalid JSON when key/value pairs are removed Created: 08/Jan/13  Updated: 10/Jan/14  Resolved: 02/Apr/13

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Fred Caton Assignee: Stuart Sierra
Resolution: Completed Votes: 1
Labels: None
Environment:

clojure.data.json 0.2.0


Attachments: Text File djson-7-dont-write-unnecessary-commas-v1.txt    
Patch: Code and Test

 Description   

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



 Comments   
Comment by Andy Fingerhut [ 22/Jan/13 12:29 AM ]

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.

Comment by Stuart Sierra [ 02/Apr/13 7:05 PM ]

Patch applied.

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-8] write-json is documented to write to arg out, but instead writes to *out* Created: 27/Mar/13  Updated: 10/Jan/14  Resolved: 02/Apr/13

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andy Fingerhut Assignee: Stuart Sierra
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File djson-8-correct-write-json-patch-v1.txt    

 Description   

The summary pretty much says it all.



 Comments   
Comment by Andy Fingerhut [ 27/Mar/13 6:50 PM ]

Patch djson-8-correct-write-json-patch-v1.txt dated Mar 27 2013 is a simple one-line fix.

Comment by Stuart Sierra [ 02/Apr/13 7:06 PM ]

Already fixed in commit d3cce5b200031cf22603c13a9a39e3939651d344

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-14] read-escaped-char doesn't handle EOF correctly Created: 28/Oct/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Alexander Kiel Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File djson-14.patch    
Patch: Code and Test

 Description   

The function read-escaped-char doesn't check the int read from stream for negative values meaning end-of-file. So if you call:

(json/read-str "\"\\")

it returns

IllegalArgumentException No matching clause: -1  clojure.data.json/read-escaped-char (json.clj:122)


 Comments   
Comment by Alexander Kiel [ 28/Oct/13 5:01 AM ]

Quick view of patch on github: https://github.com/alexanderkiel/data.json/compare/djson-14

Comment by Stuart Sierra [ 10/Jan/14 10:12 AM ]

Patch was not in proper `git am` format. Fixed anyway on Git `master`.

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-9] Always escape U+2028 and U+2029 to be nice to broken JSON parsers Created: 28/Apr/13  Updated: 10/Jan/14  Resolved: 02/Aug/13

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Tim McCormack Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Escape-JS-forbidden-unicode-chars-to-be-nice-to-brok.patch    

 Description   

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.



 Comments   
Comment by Tim McCormack [ 28/Apr/13 9:46 PM ]

Attached patch.

Comment by Stuart Sierra [ 02/Aug/13 3:25 PM ]

Reimplemented as an additional optional argument on master.

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





[DJSON-16] Add positional tracking to JSON reader Created: 18/May/14  Updated: 06/Jun/14  Resolved: 06/Jun/14

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Tim Clemons Assignee: Stuart Sierra
Resolution: Declined Votes: 0
Labels: enhancement, errormsgs, patch

Attachments: Text File 0001-Explicity-define-whitespace-characters.patch     Text File 0002-Add-position-tracking-to-reader.patch     Text File 0003-Add-line-and-column-information-to-read-exceptions.patch     Text File 0004-Add-stack-of-structure-starting-points-to-reader.patch     Text File 0005-Add-track-pos-argument-to-read.patch     Text File 0006-Replace-instances-of-printf-with-format.patch    
Patch: Code and Test

 Description   

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.



 Comments   
Comment by Tim Clemons [ 27/May/14 4:37 PM ]

FYI, it appears my Contributor Agreement has been received and processed: http://clojure.org/contributing

Comment by Stuart Sierra [ 06/Jun/14 3:24 PM ]

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.





[DJSON-6] Exception message in string reader says it is an array reader problem Created: 14/Dec/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Stefan Kamphausen Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: File djson-6-patch.diff     File djson-6-tests-patch.diff    

 Description   

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.



 Comments   
Comment by Stefan Kamphausen [ 14/Dec/12 5:26 AM ]

Trivial patch which changes the error message.

Comment by Stefan Kamphausen [ 14/Dec/12 5:53 AM ]

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

Comment by Stuart Sierra [ 18/Jan/13 8:57 AM ]

applied, with slight modifications





[DJSON-15] A test is written incorrectly so that it tests nothing Created: 23/Dec/13  Updated: 10/Jan/14  Resolved: 10/Jan/14

Status: Closed
Project: data.json
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Trivial
Reporter: Andy Fingerhut Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: File djson-15-v1.diff    

 Description   

This test has the structure (is (= expr1) expr2), which can never fail, and tests nothing:

(deftest object-keys-must-be-strings
  (is (= "{\"1\":1,\"2\":2") (json-str (sorted-map 1 1 2 2))))

Found using a pre-release version of the Eastwood Clojure lint tool.



 Comments   
Comment by Andy Fingerhut [ 23/Dec/13 5:43 PM ]

Patch djson-15-v1.diff corrects the test, including adding a missing } character to the string to compare against.

Comment by Stuart Sierra [ 10/Jan/14 11:10 AM ]

Marking old issues as 'closed'





Generated at Sat Nov 22 19:19:52 CST 2014 using JIRA 4.4#649-r158309.