org json vs google gson

[mspiegel]

I don't mean to cause controversy but what's the merit of using org.json rather than gson? The org.json license is not accepted within most corporations which prevents the use of otherwise great projects. See https://dzone.com/articles/jsonorg-license-literally-says. Is org.json significantly faster than gson? Is it more popular than gson? I don't mind submitting a pull request that would move it to gson, I don't think that would be a lot of work.

[erosb]

It isn't really a good question here, since this project is not the org.json library itself but a json-schema implementation on the top of it. Maybe better to ask at this repo: https://github.com/stleary/JSON-java

Anyway, IMO

Is org.json significantly faster than gson?

GSON is a data mapping library, involving a massive use of reflection (you map JSON to arbitary java objects), while org.json is a generic JSON representation (it parses json strings itno JSONObject and JSONArray instances), and a DSL for generating JSON text (with JSONWriter). So the scope of the two libraries are slightly different. Due to GSON being more reflection-heavy, I think it is probably significantly slower than org.json, but I've never measured it.

Is it more popular than gson?

Not at all. I can see GSON and Jackson being the most popular solutions for managing JSON data in the java world.

I don't mind submitting a pull request that would move it to gson, I don't think that would be a lot of work.

GSON is, as far as I'm concerned, is a data mapping library, so the schema is specified by the java classes you serialize JSON from/to. Supporting GSON with a json-schema library just doesn't make sense for me, but maybe I'm wrong.

[mspiegel]

https://github.com/stleary/JSON-java has a license with the clause "The Software shall be used for Good, not Evil." It's not productive to post an issue with that repository because Douglas Crockford added that clause to his project and he is not interested in removing it. I don't really have a problem with that part of the license. It's just I can't use that library for my work projects because the lawyers won't let me.

Because this library uses that library as a dependency, I can't use this library either for work. Sorry it's been about half a year since I've used json libraries in Java I forgot that GSON was more than just a parsing library. It's a shame there are not more small json parsing libraries for Java.

What if this library used only the json parsing functionality from GSON? I saw there is a parser in GSON. I don't mind doing the work and submitting a pull request. But if there's not an interest in moving away from the org.json parser then I won't do unnecessary work.

[erosb]

It is a petty that the license of the org.json library causes you trouble.

I think if we want to provide a way in this library to avoid the use of org.json, then:

• the solution should be API-compatible with the current code, I don't like the idea of bumping the major version to 2.x (since maintaining an 1.x and a 2.x branch would cause me severe overhead)
• introducing jackson core support probably makes more sense than copy-pasting code from GSON. Jackson core, unlike GSON, is quite close in concept to org.json

If you feel ambitious to work on it, then you can create a proof of concept and send a PR. But I'm not sure if this can be achieved without breaking the current API.

[mspiegel]

That sounds like a reasonable strategy. I'll see what I can do.
On Jun 19, 2016 2:38 PM, "Bence Eros" notifications@github.com wrote:

It is a petty that the license of the org.json library causes you trouble.

I think if we want to provide a way in this library to avoid the use of
org.json, then:

• the solution should be API-compatible with the current code, I don't
  like the idea of bumping the major version to 2.x (since maintaining an 1.x
  and a 2.x branch would cause me severe overhead)
• introducing jackson core support probably makes more sense than
  copy-pasting code from GSON. Jackson core, unlike GSON, is quite close in
  concept to org.json

If you feel ambitious to work on it, then you can create a proof of
concept and send a PR. But I'm not sure if this can be achieved without
breaking the current API.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#37 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAtnU2yuANG353InZVOq8IvVS8x02o9ks5qNYy1gaJpZM4I4qNd
.

[sunray2003]

I am running to same licensing issue within my company about org.json and I was wondering if this discussion got any where.

[bannmann]

There is a clean-room implementation of the json.org API that was created as part of the Android project. It can be found on Maven central at com.vaadin.external.google:android-json. Somebody should test whether json-schema works with it. Unfortunately, I don't have the time to do it myself.

[erosb]

Hello, this project is now superseded by erosb/json-sKema which has its own json parser and doesn't have such library dependency. Closing this issue.