Replace ReflectionCheckingTypeAdapterFactory with a ReflectionAccessFilter

[richardm-stripe]

Notify

r? @stripe/api-library-reviewers

Summary

Fixes #1494

• Updates GSON by a patch version.
• Removes ReflectionCheckingTypeAdapterFactory -- this should be non breaking as the visibility is package-private.
• Adds a ReflectionAccessFilter (new in Gson 2.9.1) as a replacement.

I have NOT actually set up a project to reproduce #1494, but I am still highly confident this will fix it as it is completely removing the class with the suspect import statement.

Context

Basically, we want to throw an exception when GSON is asked to use reflection and deserialize a class that isn't beneath com.stripe., usually this happens when the class has an "infrastructure" field that doesn't represent data, but the field is not marked "transient", e.g. in #1197 the issue was that StripeCollection had a private RequestOptions requestOptions that should have been private transient RequestOptions requestOptions. ("transient" is a Java keyword that means "shouldn't be serialized"). The ReflectionCheckingTypeAdapter was added to give a better error message and help prevent us from making mistakes like this again (the error message in #1190 is pretty hard to interpret), but the ReflectionAccessFilter should do the same thing without causing the module path issues mentioned in #1494.

[pakrym-stripe]

This is such an amazing find! There's barely a mention of addReflectionAccessFilter on the internet. Are we worried that this feature is too new and will break customers that have older GSON versions?

[richardm-stripe]

All credit goes to Marcono1234 who commented on #1197.

Stripe-java presently needs GSON >= 2.8.2 (when JsonElement.deepCopy was added used here), from 2017.

By SemVer, 2.9.1 should be completely backwards compatible with 2.8.2 so in theory any user upgrading stripe-java should also be able to upgrade GSON without problems.

This is five years of GSON versions we lose compatibility with, but I don't think we should default to assuming SemVer is untrustworthy and users won't be able to update. If we ever get any feedback about a versioning conflict, we can always release a newer version with a workaround.