* Build on JDK 8 and 17 as well as 11.
* Remove JDK 8 for now.
`DefaultDateTypeAdapterTest` fails.
* Tweak javadoc to avoid warnings.
Mostly these are about using `<h3>` when the previous tag was `<h1>`,
and the like. This previous tag might be implicit (part of what javadoc
itself outputs rather than the HTML in doc comments).
Apparently JDK 11 puts method javadoc inside `<h2>` while JDK 11 puts it
inside `<h3>`. Or something like that. Anyway it doesn't appear to be
possible to use `<h3>` _or_ `<h4>` and please both.
* Add support for reflection access filter
* Improve documentation
* Fix compilation errors
* Relax handling for BLOCK_ALL when invoking default constructor
* Improve handling for inherited fields
* Fix accessible test failing for static fields
* Simplify ReflectiveTypeAdapterFactory field writing
* Fix GsonBuilder changes affecting created Gson instances
* Improve documentation
* Improve handling for IllegalAccessException
For Java < 9, AccessibleObject.canAccess is not available and therefore checks
might pass even if object is not accessible, causing IllegalAccessException
later.
* Fix incorrect GsonBuilder.addReflectionAccessFilter documentation
* 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>
I actually tried to replicate this test but got an error "type adapters conflict" when I was doing it. I suspect the problem was that I was trying to use 'Object' as the base of my type hierarchy and that class is somehow special.
This drops support for type hierarchy instance creators. I don't expect this to be a problem. We'll also detect fewer errors where multiple type adapters can serialize the same type. With APIs like getNextTypeAdapter, I think this might actually be an improvement!
revised GsonBuilder.registerTypeAdapter/registerTypeHierarchyAdapter to take streaming type adapters as well. Removed the typeAdapter() and typeHierarchyAdapter() methods from the public API.
- The cache interface has only one implementation. Drop the interface; we can add it back later if necessary.
- The DefaultTypeAdapters class contains one member class. Just make that a top-level class.
The motivation for this change is to give tree-style adapters precedence order in registration. This fixes the test I committed earlier today, where registration order was not honored.
This renamed ParameterizedTypeHandlerMap to the shorter 'TypeMap'. For type adapters, this is now only used for type hierarchy. We still need non-hierarchy support in TypeMap for instance creators; I'll be looking for workarounds to see if further simplification is possible here.
