[Marcono1234]

Follow-up for #1689.

Creating custom JsonElement subclasses is discouraged and will lead to issues when using JsonTreeReader.

[Marcono1234]

@eamonnmcmanus, could you please have a look?

[eamonnmcmanus]

Thanks! I agree with the principle. I had a couple of small comments.
Another approach that would avoid having so many @SuppressWarnings("deprecation") annotations would be to have a second, package-private JsonElement constructor with a dummy parameter, and use that in the subclasses. But I think @SuppressWarnings is probably better.

[eamonnmcmanus]

I think I would write:

assertEquals("Custom JsonElement subclass " + CustomSubclass.class.getName() + " is not supported", ...)

[Marcono1234]

Good point, that hardcoded generated name JsonTreeReaderTest$1CustomSubclass would likely cause problems in the future.

[eamonnmcmanus]

Experimentally, I tried just changing the JsonElement constructor to package-private and testing that against all of Google's internal code. There were no failures. So, even though it is technically an incompatible API change, I think maybe we could allow ourselves to make it. Clearly the existing default public constructor was an oversight.

[Marcono1234]

So, even though it is technically an incompatible API change, I think maybe we could allow ourselves to make it. Clearly the existing default public constructor was an oversight.

To be safe, I think keeping the constructor for now might be better because at least the Auto.js project has a custom subclass. Also, unlike some other issues, keeping the deprecated JsonElement constructor would probably not be such a big problem; and we can still remove it in the future.

[eamonnmcmanus]

OK, given that we know of one subclass I agree that the change here is the right way to go.