Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move JSONString out of split package #167

Closed
wants to merge 1 commit into from

Conversation

zrbrown
Copy link

@zrbrown zrbrown commented Nov 11, 2022

This removes the org.json package as it's a split package with the one in android-json, fixing usages in the module system introduced in Java 9.

JSONString has been moved to org.skyscreamer.jsonassert. As far as I can tell, the reason this was in a split package to begin with is to allow JSONString implementers to have access to package-private methods in android-json's org.json.

The package-private methods/fields are:

  • JSONStringer
    • JSONStringer(int indentSpaces)
    • JSONStringer open(Scope empty, String openBracket)
    • JSONStringer close(Scope empty, Scope nonempty, String closeBracket)
    • final StringBuilder out
    • enum Scope
  • JSON
    • static double checkDouble(double d)
    • static Boolean toBoolean(Object value)
    • static Double toDouble(Object value)
    • static Integer toInteger(Object value)
    • static Long toLong(Object value)
    • static String toString(Object value)
  • JSONObject
    • String checkName(String name)
    • void writeTo(JSONStringer stringer)
  • JSONArray
    • void writeTo(JSONStringer stringer)

So if you wanted to create your own "JSONThing", these methods are clearly pretty useful. I don't know how common it is to do this, but I imagine most consumers are just using JSONAssert, like Spring does. I'd argue that anyone using these package-private methods is skilled enough to just make them accessible via reflection, so while this is a breaking change, I don't think it's that bad.

Given it is a breaking change however, maybe this PR can be targeted to a 2.0 release? I'm not sure how committed you are to semantic versioning, but I'm pretty indifferent as long as this gets merged :). Thanks!

@zrbrown
Copy link
Author

zrbrown commented Dec 2, 2022

Actually, I wasn't thinking right - the fact that the interface is in org.json has no bearing on the access to org.json from implementers. So this change seems even safer, as the only thing that will change is the package location.

@carterpage
Copy link
Member

Thanks for your submission. This should be address in #194.

A few more things were needed to make the change, including handling the change of JSONException to a RuntimeException.

@carterpage carterpage closed this Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants