This PR fixes an inconsistency in $Gson$Types#resolve() where the ParameterizedType#getActualTypeArguments() array is only cloned when the resolved owner-type has not changed from the original owner-type.
Description
In most cases this is a non-issue, as usually all ParameterizedType implementations clone the array themselves when invoking the getActualTypeArguments() getter. However, this is not guaranteed.
Cloning the array only when the owner-type didn't change seems like an inconsistency and an oversight, so this PR is trying to fix that.
Checklist
[x] New code follows the Google Java Style Guide\
This is automatically checked by mvn verify, but can also be checked on its own using mvn spotless:check.\
Style violations can be fixed using mvn spotless:apply; this can be done in a separate commit to verify that it did not cause undesired changes.
[ ] If necessary, new public API validates arguments, for example rejects null
[ ] New public API has Javadoc
[ ] Javadoc uses @since $next-version$
($next-version$ is a special placeholder which is automatically replaced during release)
[ ] If necessary, new unit tests have been added
[ ] Assertions in unit tests use Truth, see existing tests
[ ] No JUnit 3 features are used (such as extending class TestCase)
[ ] If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
[x] mvn clean verify javadoc:jar passes without errors
Purpose
This PR fixes an inconsistency in
$Gson$Types#resolve()
where theParameterizedType#getActualTypeArguments()
array is only cloned when the resolved owner-type has not changed from the original owner-type.Description
In most cases this is a non-issue, as usually all
ParameterizedType
implementations clone the array themselves when invoking thegetActualTypeArguments()
getter. However, this is not guaranteed. Cloning the array only when the owner-type didn't change seems like an inconsistency and an oversight, so this PR is trying to fix that.Checklist
mvn verify
, but can also be checked on its own usingmvn spotless:check
.\ Style violations can be fixed usingmvn spotless:apply
; this can be done in a separate commit to verify that it did not cause undesired changes.null
@since $next-version$
(
$next-version$
is a special placeholder which is automatically replaced during release)TestCase
)mvn clean verify javadoc:jar
passes without errors