Package interface is not compatible with original org.json.*

[mfursov]

My project uses both this package and Google Firebase. As the result I have this error:

java.lang.NoSuchMethodError: org.json.JSONStringer.object()Lorg/json/JSONWriter;
at com.google.firebase.database.util.JsonMapper.serializeJsonValue(JsonMapper.java:56)
at com.google.firebase.database.util.JsonMapper.serializeJsonValue(JsonMapper.java:45)
at com.google.firebase.database.util.JsonMapper.serializeJson(JsonMapper.java:25)
at com.google.firebase.database.util.GAuthToken.serializeToString(GAuthToken.java:53)
at com.google.firebase.database.core.JvmAuthTokenProvider$1.onComplete(JvmAuthTokenProvider.java:40)
at com.google.firebase.tasks.OnCompleteCompletionListener$1.run(OnCompleteCompletionListener.java:37)

Reason: Google libraries uses one library and Wicket uses another by the same name. These 2 libraries are in conflict.

I would suggest to have 100% compatible API with the latest version of the original package or change package name.

https://search.maven.org/#artifactdetails%7Ccom.google.firebase%7Cfirebase-server-sdk%7C3.0.3%7Cjar

[tdunning]

Can you suggest what semantics and API points you want? There isn't an actual specification available and I don't want to compromise the clean-room status of open json. Test cases would be very helpful.

…

On Tue, Feb 28, 2017 at 3:37 AM, Mikhail Fursov ***@***.***> wrote: My project uses both this package and Google Firebase. As the result I have this error: java.lang.NoSuchMethodError: org.json.JSONStringer.object() Lorg/json/JSONWriter; at com.google.firebase.database.util.JsonMapper. serializeJsonValue(JsonMapper.java:56) at com.google.firebase.database.util.JsonMapper. serializeJsonValue(JsonMapper.java:45) at com.google.firebase.database.util.JsonMapper.serializeJson( JsonMapper.java:25) at com.google.firebase.database.util.GAuthToken. serializeToString(GAuthToken.java:53) at com.google.firebase.database.core.JvmAuthTokenProvider$1.onComplete( JvmAuthTokenProvider.java:40) at com.google.firebase.tasks.OnCompleteCompletionListener$1.run( OnCompleteCompletionListener.java:37) Reason: Google libraries uses one library and Wicket uses another by the same name. These 2 libraries are in conflict. I would suggest to have 100% compatible API or do not use the same package name. https://search.maven.org/#artifactdetails%7Ccom.google. firebase%7Cfirebase-server-sdk%7C3.0.3%7Cjar — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPSegkmorxymoJm6tVdf6NLh1uz9XU8ks5rg5ZfgaJpZM4MN7fN> .

[martin-g]

@tdunning I think the real problem is that OpenJson uses org.json as package name. This way it clashes badly with Douglas Crockford's JSON library.
Some projects (like Wicket) bring OpenJson as dependency, others (like Google Firebase) bring the old JSON library. At the end the JVM picks the class (e.g. JSONObject) from the one that is earlier in the constructed classpath.
IMO in the long run it would be safer if OpenJson changes its package name to org.openjson or something like that.

[tdunning]

Well, the point here is to completely replace the Crockford's library since he refuses to release it under an open source license. As such, exactly emulating the API to the degree that could be discerned was necessary because Wicket had a deadline to remove the original org.json library. If you care about your code being open source and distributable, then you might want to consider dependency surgery to get Firebase to not use the problematic dependency. If you can specify what functionality that would require, then I am happy to look at implementing it. I am a little surprised that Firebase uses Crockford's non-open library, however, since Google did a clean-room re-implementation (that I used as a base) for Android.

…

On Tue, Feb 28, 2017 at 8:42 AM, Martin Grigorov ***@***.***> wrote: @tdunning <https://github.com/tdunning> I think the real problem is that OpenJson uses org.json as package name. This way it clashes badly with Douglas Crockford's JSON library. Some projects (like Wicket) bring OpenJson as dependency, others (like Google Firebase) bring the old JSON library. At the end the JVM picks the class (e.g. JSONObject) from the one that is earlier in the constructed classpath. IMO in the long run it would be safer if OpenJson changes its package name to org.openjson or something like that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPSepeOXHXMUmRBPHTkU8WdFHyrGBpWks5rg93zgaJpZM4MN7fN> .

[mfursov]

I support Martin that using unique package name is the best solution.

Reasons:

• The 'old' library has multiple releases. The latest is dated by 2016. For some people this project is alive: https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.codeartisans%22%20AND%20a%3A%22org.json%22

• There are 1000+ projects that relies on old code: https://mvnrepository.com/artifact/org.json/json
  Having any of them in classpath may cause runtime (not compile time) issues.

• It is actually a big work to support all methods from 'org.json'. It also includes XML support :)

[tdunning]

That may well be, but the point of open JSON is to provide a *temporary* plug compatible replacement for projects like wicket or hadoop who need to get rid of the old library immediately. Over the longer term, switching to Jackson is the right thing to do. Open JSON is not a long-term solution. So, I repeat my limited offer. If you have a limited addition to the API, I am happy to help. Changing the package name, however, is off the table because it conflicts with the primary goal.

…

On Feb 28, 2017 6:41 AM, "Mikhail Fursov" ***@***.***> wrote: I support Martin that using unique package name is the best solution. Reasons: - The 'old' library has multiple releases. The latest is dated by 2016. For some people this project is alive: https://search.maven.org/# search%7Cgav%7C1%7Cg%3A%22org.codeartisans%22%20AND%20a%3A% 22org.json%22 <https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.codeartisans%22%20AND%20a%3A%22org.json%22> - There are 1000+ projects that relies on old code: https://mvnrepository.com/artifact/org.json/json <https://mvnrepository.com/artifact/org.json/json> Having any of them in classpath may cause runtime (not compile time) issues. - It is actually a big work to support all methods from 'org.json'. It also includes XML support :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPSek-1x1--jA8K2SF1wFYia0THgNVsks5rhDIBgaJpZM4MN7fN> .

[mfursov]

If the primary goal is to get rid of old code why package name is so important?
In Wicket, for example, the package name today is not org.json but org.apache.wicket.ajax.json.

Another example could be: when Sun included Xerces into JDK - they changed the package name for the same reason: to avoid conflicts.

About 'limited addition to API': you either 100% compatible or not. 1000+ projects in Maven depends on original features of json.org. Some of them from Google, some from Spring, some from Apache. Why to have this problem at all?

Missing any of class, method, constant, code behavior is a hidden bug that will reveal itself in runtime.

[mfursov]

Here is jardiff report.
changes.html.zip

[solomax]

I would like to come up with an alternative solution:
Maybe additional branch like 2.0 can be created and will have 2.X.X version and different package name
So users willing to use simple fully open library can switch to 2.x.x once
Others can use 1.x.x with old name as "short term" solution

WDYT?

[mfursov]

I would definitely like this project and contribute to it. I'm a happy user of 'JSONObject' library for many years. This library has a lot of benefits for me when compared to other solutions: it's simple, it has smaller jar size, it has no dependencies, it has better performance than Jackson (checked for parsing 4mb json files).

I do not like original https://github.com/stleary/JSON-java copy because it has no LinkedHashMap inside of JSONObject and the maintainer of the library refuses to accept any related fixes, however 3rd party datasets I depend upon rely on ordering in JSON to optimize data size. So Wicket impl was perfect for me and I would definitely contribute to another version that follows the same goals.

BTW, Hi Max :) Long time no see!

[mfursov]

just for fun: below are benchmark results for this package vs org.json:
(benchmark origin: https://github.com/RichardHightower/json-parsers-benchmark)

Benchmark                                Mode Thr     Count  Sec         Mean 

i.g.j.s.OrgJsonBenchmark.actionLabel    thrpt   8         3    1   409515.806
i.g.j.s.OpenjsonBenchmark.actionLabel   thrpt   8         3    1   860833.050

i.g.j.s.OrgJsonBenchmark.citmCatalog    thrpt   8         3    1      280.911
i.g.j.s.OpenjsonBenchmark.citmCatalog   thrpt   8         3    1      508.311

i.g.j.s.OrgJsonBenchmark.medium         thrpt   8         3    1   176217.306
i.g.j.s.OpenjsonBenchmark.medium        thrpt   8         3    1   605602.511

i.g.j.s.OrgJsonBenchmark.menu           thrpt   8         3    1  1425624.972
i.g.j.s.OpenjsonBenchmark.menu          thrpt   8         3    1  2547549.411

i.g.j.s.OrgJsonBenchmark.sgml           thrpt   8         3    1   628004.661
i.g.j.s.OpenjsonBenchmark.sgml          thrpt   8         3    1  1447232.944

i.g.j.s.OrgJsonBenchmark.small          thrpt   8         3    1  8125230.083
i.g.j.s.OpenjsonBenchmark.small         thrpt   8         3    1 11046816.617

i.g.j.s.OrgJsonBenchmark.webxml         thrpt   8         3    1   106045.972
i.g.j.s.OpenjsonBenchmark.webxml        thrpt   8         3    1   337826.061

i.g.j.s.OrgJsonBenchmark.widget         thrpt   8         3    1   401139.761
i.g.j.s.OpenjsonBenchmark.widget        thrpt   8         3    1   911970.478

[martin-g]

Another candidate to switch to OpenJson: Apache Tapestry.
I will cross link the issues so they are aware of our current findings.

https://issues.apache.org/jira/browse/TAP5-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897115#comment-15897115

[solomax]

@martin-g should I move wicketstuff projects to com.github.openjson?
@mfursov I see lots of commits :) when are you planning first release?

[mfursov]

Max,

All these commits are tests only. I see no reasons for any new release until some real issues fixed.

Originally I thought the package should be 100% compatible with original 'org.json' and started implementing missed parts, but later removed all these changes: I understood and appreciated the way the package was minified. Really good job.

So, 'com.github.openjson' package is 100% the same as this package now.

I'm going to add missed tests, want to make github to understand the licence correctly (some external tools like 'versioneye' depends on it) - but all these are infrastructure related changes only, not API.

[solomax]

Why I'm asking: Wicket is now in Milestone period (8.0.0-M4), and all major changes are only allowed in this period
So I guess it might worth to release this artifact with new coordinates, so wicket can receive updates after 8.0.0 will be finalized ...