Move JSONString out of split package #167
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removes the
org.json
package as it's a split package with the one inandroid-json
, fixing usages in the module system introduced in Java 9.JSONString
has been moved toorg.skyscreamer.jsonassert
. As far as I can tell, the reason this was in a split package to begin with is to allowJSONString
implementers to have access to package-private methods inandroid-json
'sorg.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!