* Make Object and JsonElement deserialization iterative
Often when Object and JsonElement are deserialized the format of the JSON
data is unknown and it might come from an untrusted source. To avoid a
StackOverflowError from maliciously crafted JSON, deserialize Object and
JsonElement iteratively instead of recursively.
Concept based on 51fd2faab7
But implementation is not based on it.
* Improve imports grouping
* Address review feedback
* Object and Number type adapters number deserialization can be configured
* Change wording of ToNumberStrategy documentation
* Use inline links in doc sparingly
If the element has already been linked before, don't create a link for
every subsequent occurrence.
See also (slightly dated)
https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#inlinelinks
* Link to default to-number policies in ToNumberStrategy doc
* Reduce code duplication for deserializing Number
* Hide default factory constants of NumberTypeAdapter and ObjectTypeAdapter
This encapsulates the logic a little bit better.
Additionally refactored factory created by NumberTypeAdapter to only create
TypeAdapter once and then have factory reuse that adapter for better
performance.
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
The most notable impact of this change is that it adds several new public APIs:
- The TypeAdapter abstract class
- The TypeAdapter.Factory interface
- Four new methods on GsonBuilder to register streaming TypeAdapters (via Factory, via Class, via TypeToken, and as a type hierarchy)
- Three new methods on Gson to lookup streaming TypeAdapters (by type, by class, and to get the next type adapter)
Still outstanding:
- Write beautiful prose to document the new APIs above
- Change GsonBuilder's precedence so that both old and new-style type adapters are registered in one lot
