Small modifications to make building a subset possible.

[eamonnmcmanus]

The changes here make it possible to build a subset of Gson that includes JsonReader, JsonWriter, JsonParser, and JsonElement and its subclasses, but does not include the Gson class or the standard TypeAdapter classes. The idea is that this subset avoids the problematic uses of reflection that make Gson inappropriate for use on Android and similar platforms.

This change makes the class com.google.gson.internal.bind.JsonElementTypeAdapter public, which is convenient but of course means that people are going to start referencing it despite the .internal. in its name. However, they can already reference TypeAdapters.JSON_ELEMENT in the same package, so we're not really exposing anything new.

The subsetting is currently designed to be used internally at Google. At a later date, we may release a new artifact containing just the subset.

[cpovirk]

At a later date, we may release a new artifact containing just the subset.

Just to state the obvious in public: This would complicate the story with the Java module system, as we've experienced with Guava's listenablefuture artifact (which largely worked around that while introducing new and exciting problems). I wonder if the better solution in Gson's case might be to introduce matching APIs in a new package or something, since we don't need to worry as much about "API types" as we did with Guava? But we can cross that bridge when we come to it.

[cpovirk]

(I don't think we accomplish this in Maven currently, but eamonnmcmanus has some Google-internal wiring underway to confirm that this does work with the planned subset. And of course, you'd hope that the hard part is identifying a subset and getting it to compile in the first place, at which point you'd expect any tests that compile against that subset to pass just as they had before :))

[Marcono1234]

Would it be useful to add a build config which ensures that building this subset works? Maybe something like https://github.com/Marcono1234/gson/tree/marcono1234/gson-subset (see latest commit)

I am a bit concerned though if that could confuse external contributors, even if the GitHub workflow uses continue-on-error: true for that job, because the GitHub UI might still display that specific job as failed even if the workflow as a whole is considered successful.

[eamonnmcmanus]

Would it be useful to add a build config which ensures that building this subset works? Maybe something like https://github.com/Marcono1234/gson/tree/marcono1234/gson-subset (see latest commit)

That would be very helpful! I have some comments on your commit, but those could wait until it is a PR. (One thing, though: it would be helpful to sort the list of included source files.)

I am a bit concerned though if that could confuse external contributors, even if the GitHub workflow uses continue-on-error: true for that job, because the GitHub UI might still display that specific job as failed even if the workflow as a whole is considered successful.

I think it would actually be better not to have continue-on-error. If an external contribution breaks the subset, I think we want to know about it.

[Marcono1234]

I have some comments on your commit, but those could wait until it is a PR

Ok, have created #2947