Skip to content

Conversation

@Marcono1234
Copy link
Contributor

Purpose

Resolves #2445

Description

See #2445 for the rationale.

With these changes an exception is thrown when users try to serialize or deserialize unsupported JSON classes from other libraries.

Currently detected libraries:

  • JSON-java / Android (org.json.JSONArray, org.json.JSONObject)
  • Vert.x

Also a new Troubleshooting Guide entry has been added explaining the issue and for JSON-java / Android suggesting backward compatible TypeAdapterFactory implementations.

Checklist

  • New code follows the Google Java Style Guide
  • If necessary, new public API validates arguments, for example rejects null
  • New public API has Javadoc
    • Javadoc uses @since $next-version$
      ($next-version$ is a special placeholder which is automatically replaced during release)
  • If necessary, new unit tests have been added
    • Assertions in unit tests use Truth, see existing tests
    • No JUnit 3 features are used (such as extending class TestCase)
    • If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
  • mvn clean verify javadoc:jar passes without errors

<artifactId>json</artifactId>
<!-- Uses an ancient version because it matches roughly the API of the same classes from Android
See also https://stackoverflow.com/q/39564936 -->
<version>20090211</version>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not very happy about using such an outdated test dependency, especially because that version does not even have source code or Javadoc available, but it matches the Android API closely and therefore makes it easier to verify that the code in the JsonOrgInteropTest test class (which is also shown in the Troubleshooting Guide) compiles for Android as well.

}
}

private static class JSONArraySubject extends JsonOrgBaseSubject {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe having these custom Truth Subject classes is a bit exaggerated, and they might not follow Truth best practices (feedback is welcome). Though on the other hand they make comparison of JSONArray and JSONObject easier.

@Marcono1234 Marcono1234 marked this pull request as ready for review July 29, 2023 14:01
@Marcono1234
Copy link
Contributor Author

The code suggested in the troubleshooting guide to keep backward compatibility with the previous reflection-based output for JSONArray and JSONObject might be a bit too verbose. Maybe it should be removed (also from the unit test).

If necessary we could possibly consider adding a system property for now which still allows users to use reflection on those classes, but mention that the system property will be removed in future Gson versions.

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.

Throw exception when using classes from other JSON libraries with Gson

1 participant