Skip to content

Conversation

mfriesen
Copy link
Contributor

Purpose

This pull request enhances the FieldNamingStrategy in Gson to support returning multiple strings for a field name. This behavior aligns with the alternate names functionality provided by the @SerializedName annotation, allowing for greater flexibility in field mapping.

Description

The FieldNamingStrategy interface 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 FieldNamingStrategy interface to support returning a collection of names. This allows the FieldNamingStrategy interface to behave like the @SerializedName annotation.

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.
  • [X ] If necessary, new public API validates arguments, for example rejects null
  • [X ] New public API has Javadoc
    • [ X] Javadoc uses @since $next-version$
      ($next-version$ is a special placeholder which is automatically replaced during release)
  • [ X] If necessary, new unit tests have been added
    • [ X] Assertions in unit tests use Truth, see existing tests
    • [X ] No JUnit 3 features are used (such as extending class TestCase)
    • [X ] 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

@Marcono1234
Copy link
Contributor

Thanks for this suggestion! It seems that would resolve #1002

However, we cannot change the return type of translateName from String to List<String> since that would be an incompatible change.
But what might be possible, similar to @SerializedName#alternate, is adding an additional method to FieldNamingStrategy, for example translateToAlternateNames(Field): List<String> (or a better name). The next Gson version will target Java 8, so we could provide a default implementation of this method which returns an empty list. This should preserve backward compatibility.

This is just an idea though, maybe there are other possible approaches.

@mfriesen
Copy link
Contributor Author

@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.

Copy link
Contributor

@Marcono1234 Marcono1234 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

@Marcono1234 Marcono1234 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
@mfriesen
Copy link
Contributor Author

@Marcono1234 Is there anything else I need to do for this PR?

Copy link
Member

@eamonnmcmanus eamonnmcmanus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

The parameter 'f' is never used.
Copy link
Member

@eamonnmcmanus eamonnmcmanus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Just a couple of small things...

Copy link
Contributor

@Marcono1234 Marcono1234 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for updating this pull request! I have also added some small suggestion comments, hopefully that is ok for you.

Copy link
Member

@eamonnmcmanus eamonnmcmanus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, but I will wait for @Marcono1234 before merging.

@eamonnmcmanus eamonnmcmanus merged commit 4e65e6a into google:main Apr 13, 2025
11 checks passed
@Marcono1234
Copy link
Contributor

@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.

@eamonnmcmanus
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants