Disables the download transfer progress which is shown when Maven downloads
(or uploads) artifacts which are not available in the local repository.
This download progress can be quite verbose and is normally not that relevant.
* Add a currently-failing test for Java records and `@Ignore` it.
Also do the Maven gymastics required to ensure that this test only runs on Java
versions ≥17. (It would also work on Java 16, but 17 is all we have in the CI.)
Fix some compilation problems I saw when running locally, which for some reason
don't show up in the CI.
* Suppress some new lint options that trigger `-Werror`.
We may fix these later. (Every test will need an explicit constructor!)
* Select Java version with maven.compiler.release and maven.compiler.testRelease.
Use `assumeNotNull` rather than an if-statement.
* Specify <release>11</release> for javadoc.
* Restore the @see for AccessibleObject.
* 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 Gson.fromJson(..., TypeToken) overloads
Previously only Gson.fromJson(..., Type) existed which is however not
type-safe since the generic type parameter T used for the return type is
not bound.
Since these methods are often used in the form
gson.fromJson(..., new TypeToken<...>(){}.getType())
this commit now adds overloads which accept a TypeToken and are therefore
more type-safe.
Additional changes:
- Fixed some grammar mistakes
- Added javadoc @see tags
- Consistently write "JSON" in uppercase
- More precise placement of @SuppressWarnings("unchecked")
* Add to Gson.fromJson javadoc that JSON is fully consumed
The newly added documentation deliberately does not state which exception
is thrown because Gson.assertFullConsumption could throw either a
JsonIOException or a JsonSyntaxException.
* Remove unnecessary wrapping and unwrapping as TypeToken in Gson.fromJson
Since the actual implementation of Gson.fromJson is TypeToken based, the
TypeToken variant overloads are now the "main" implementation and the other
overloads delegate to them.
Previously the Type variant overloads were the "main" implementation which
caused `TypeToken.getType()` followed by `TypeToken.get(...)` when the
TypeToken variant overloads were used.
* Trim source code whitespaces
* Fix Gson.fromJson(JsonReader, Class) not casting read Object
To be consistent with the other Gson.fromJson(..., Class) overloads the
method should cast the result.
* Replace User Guide link in Gson documentation
* Remove more references to fromJson(..., Type)
* Extend documentation for fromJson(JsonReader, ...)
* Replace some TypeToken.getType() usages
* Address feedback; improve documentation
* Remove fromJson(JsonReader, Class) again
As noticed during review adding this method is source incompatible.
The oss-parent configuration has been applied manually to the root pom.xml,
except that now newer plugin versions are used for source and javadoc JAR
creation, and for GPG signing.
This required some reordering of the plugins for the gson module to make
sure they are executed in the correct order. Otherwise this would cause
failures for javadoc:jar.
* Verify that JsonTreeReader and JsonTreeWriter override all methods
If those classes do not override one of the JsonReader or JsonWriter methods
the user might encounter an AssertionError.
* Address review feedback
Previously when a GsonBuilder had created a Gson instance and was afterwards
reused and different type adapters were added, new GsonBuilder instances
obtained from the previous Gson instance through Gson.newBuilder() would have
been affected by the GsonBuilder changes.
This commit fixes this and additionally adds some more unit tests.
* Fix JsonReader / JsonWriter documentation regarding top-level value
RFC 7159 allows any top-level value (not only arrays or objects) [0],
however when #773 added this functionality it appears the author forgot
to update the documentation of these classes.
[0] https://tools.ietf.org/html/rfc7159#appendix-A
> Changed the definition of "JSON text" so that it can be any JSON
> value, removing the constraint that it be an object or array.
* Fix missing space
* Improve InternationalizationTest
- Remove "raw" tests since after compiling they are the same as the one with
escape sequences
- Add tests for supplementary code points (> \uFFFF)
* Improve variable names, fix incorrect escape sequences
The .gitattributes file was added to prevent GitHub detecting Gson as HTML
repository due to the included generated javadoc files. However, since
#1654 has removed the javadoc files, the .gitattributes file is no longer
needed.
* Convert null to JsonNull for `JsonArray.set`
All other methods perform the same implicit conversion.
* Mention null handling in JsonObject documentation
The JsonSerializer/Deserializer adapters used to ignore this attribute
which result in inconsistent behaviour for annotated adapters.
Fixes#1553
Signed-off-by: Dmitry Bufistov <dmitry@midokura.com>
Co-authored-by: Dmitry Bufistov <dmitry@midokura.com>
* Gson.toJson creates CharSequence which does not implement toString
* Improve Streams.AppendableWriter.CurrentWrite test
* Make setChars package-private
* Improve AppendableWriter performance
Override methods which by default create char arrays or convert
CharSequences to Strings.
This is not necessary for AppendableWriter because it can directly
append these values to the Appendable delegate.
* Add test for Streams.writerForAppendable
PR #2139 changed this factory so that if given a certain baseType, it will also
recognize any subtype of that type. That is often the right thing to do, but it
is a change in behaviour, and does in fact break at least one current client of
this code. So instead we introduce a new `recognizeSubclasses()` method that
triggers this behaviour. When the method is not called, we revert to the old
behaviour of only recognizing instances of the exact class `baseType`.
