Give FieldNamingStrategy the ability to return multiple String names#2776
Give FieldNamingStrategy the ability to return multiple String names#2776eamonnmcmanus merged 17 commits intogoogle:mainfrom
Conversation
|
Thanks for this suggestion! It seems that would resolve #1002 However, we cannot change the return type of This is just an idea though, maybe there are other possible approaches. |
|
@Marcono1234 Great idea. I wasn't sure what the best approach would be. I'll review your suggestion and see if I can get it to work. |
3bc670e to
0d769c7
Compare
0d769c7 to
94c9ea2
Compare
Marcono1234
left a comment
There was a problem hiding this comment.
Thanks for the changes!
The build currently fails due to formatting violations. You can solve this by running mvn spotless:apply.
Also note that the commits are squashed on merge here, so you don't have to force-push / rewrite commits, but instead can incrementally make changes to this pull request.
@eamonnmcmanus what do you think about these proposed changes?
- Changed fieldName to be added first to the fieldName list - test which verifies that when 'alternate names' are configured they don't affect serialization, and only affect deserialization - Updated translateToAlternateNames JavaDoc to refer it works like SerializedName#alternate()
Check Android compatibility test fails when using Stream.concat, switched to traditional Java method.
Marcono1234
left a comment
There was a problem hiding this comment.
Thanks for your changes! A few more small points, but looks good besides that.
We will however have to wait for the opinion and review from a direct Gson maintainer then.
1. Renamed badname to primary-name 2. Added test deserializing TranslateName with translateToAlternateNames
|
@Marcono1234 Is there anything else I need to do for this PR? |
eamonnmcmanus
left a comment
There was a problem hiding this comment.
Sorry, I lost sight of this. I think it makes sense. Just a couple of suggestions.
| * @return the list of possible translated field names. | ||
| * @since $next-version$ | ||
| */ | ||
| default List<String> alternateNames(Field f) { |
Check notice
Code scanning / CodeQL
Useless parameter Note
eamonnmcmanus
left a comment
There was a problem hiding this comment.
Thanks! Just a couple of small things...
Marcono1234
left a comment
There was a problem hiding this comment.
Thanks a lot for updating this pull request! I have also added some small suggestion comments, hopefully that is ok for you.
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
…eAdapterFactory.java Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
….java Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
….java Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
….java Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
eamonnmcmanus
left a comment
There was a problem hiding this comment.
This looks good to me, but I will wait for @Marcono1234 before merging.
|
@eamonnmcmanus, I think if we strictly followed SemVer, the latest version should have been 2.14.0 (instead of 2.13.1) since this PR here added a new method. But hopefully that does not matter that much. |
Yes, I realized that when it came time to draft the release notes, but I'd already published the release at that point. I agree that it doesn't matter very much. |
Purpose
This pull request enhances the
FieldNamingStrategyin Gson to support returning multiple strings for a field name. This behavior aligns with the alternate names functionality provided by the@SerializedNameannotation, allowing for greater flexibility in field mapping.Description
The
FieldNamingStrategyinterface has been updated to allow implementations to return a list of potential field name mappings. This allows deserialization to succeed if any of the alternate names are present in the JSON data.The changes include is to modifying the
FieldNamingStrategyinterface to support returning a collection of names. This allows theFieldNamingStrategyinterface to behave like the@SerializedNameannotation.Checklist
This is automatically checked by
mvn verify, but can also be checked on its own usingmvn 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.null@since $next-version$(
$next-version$is a special placeholder which is automatically replaced during release)TestCase)mvn clean verify javadoc:jarpasses without errors