mmcgrana / clj-json Goto Github PK

With a fresh checkout and a lein snapshot, lein deps runs fine, but lein compile-java fails with an exception whose stack trace begins with:

Exception in thread "main" java.lang.Exception: Unable to resolve symbol: make-path in this context (compile_java.clj:10)
        at clojure.lang.Compiler.analyze(Compiler.java:5200)

$ lein test
Jul 2, 2013 1:15:08 PM com.mchange.v2.log.MLog
INFO: MLog clients using java 1.4+ standard logging.
Exception in thread "main" java.lang.UnsupportedClassVersionError: clj_json/JsonExt : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:171)
at clj_json.core$eval185$loading__4910__auto____186.invoke(core.clj:1)
at clj_json.core$eval185.invoke(core.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6619)
at clojure.lang.Compiler.eval(Compiler.java:6608)
at clojure.lang.Compiler.load(Compiler.java:7064)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)

I think a dependency or clj-json has been compiled with Java 1.7. Maybe this is intended, I am a n00b. Is there a way to make this work on a 1.6 platform?

My project.clj:

(defproject json-test "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :main json-test.core
  :dependencies [[org.clojure/clojure "1.4.0"]
                 [clj-json "0.5.3"]
                 [clj-http "0.6.3"]])

My environment is:

% lein -v
Leiningen 2.0.0-preview10 on Java 1.6.0_24 OpenJDK 64-Bit Server VM

Is this a known fact? I ended up fixing this by turning the literals to strings.

http://stackoverflow.com/questions/16610383/remove-inst-and-uuid-literals-in-clojure

Is this the recommended procedure or am I missing something obvious? :)

The current names are a bit long, any reason to not follow HTML5 convention?

json/stringify
json/parse

Why not make json/parse polymorphic to work on strings and streams?

Just some thoughts.

Hi,

Since clojure.data.json is a big performance problem in our app (nearly 30% of request servicing time), I decided to try clj-json. Unfortunately, it isn't much of an improvement, and all because of a tiny issue. On our data, the "coerce" stage constitutes over 91% of cpu time spent in clj-json!

Since we actually do not need any coercing at all, I tested a variant of generate-string with the call to coerce removed. We get excellent performance that way.

Oh, and before you ask - this is a search engine and every millisecond counts. We really do care about performance.

Please provide a fast variant of generate-string for those of us who do not need any fancy conversions. I would submit a pull request, but it's a really simple fix, I can think of several ways this can be implemented and I think it is up to the library author to decide.

thanks,
--J.

Currently, I have to work around the fact that clj-json strips the namespace from keywords. For example:

:foo/bar => "bar"

What do you think of changing it to this:

:foo/bar => "foo/bar"

What is the reason for not using keywords in the parsed maps? It seems like Clojure idiomatically favors keys that are keywords.

I found that I was getting corrupted UTF-8 strings and it would appear to be because there is no {:escape-non-ascii true} option as with Cheshire.

In particular, U+1F601 was turning into ὠ1\xED\xB8\x81 after parsing and using generate-string.

The dev dependency [org.clojars.mmcgrana/lein-javac "1.2.1"] brings in ant-launcher-1.6.5.jar, whose version of Locator does not include the fromJarURI() method. It looks like modern lein (Leiningen 1.6.2 on Java 1.6.0_26 Java HotSpot(TM) 64-Bit Server VM for me) has a built-in javac task that wants a more modern ant-launcher. I was able to 'lein javac && lein test' without a problem after removing everything from lib/, removing the dev dependency, and running 'lein deps'.

Ok, I know this isn't very constructive since there is no pull request attached. Still:

The current parsed-seq isn't too useful. Most JSON data files contain one big object, even though the standard doesn't mandate it. So parsed-seq will just return a seq with that big object.

I have huge data files that contain an object with several fields, and each field contains a vector of objects. Here's an example:

{
    "products": [ {"data1": 1}, ... huge array of products ... ],
    "vendors": [ {}, {}, ... huge array of vendors ... ]
}

What I'd really like to have is a way to get to "products" and then get a parsed-seq of "products". When it's exhausted, I'd like to get to whatever the next field is and get a parsed-seq of that part of the tree.

This technique is described here: http://outerthought.org/blog/415-ot.html

Any chance of that happening?

Is there a method to add new data types? The ability to add new types (such as dates) to the multimethod clojure.contrib print-json allows nice flexibility.

I created a barebones project depending only on clj-json 0.5.2 and clojure 1.4. Running a script which requires clj-json fails. Problem goes away with v0.5.1.