Skip to content

Conversation

Marcono1234
Copy link
Contributor

The method is not used within the Gson code and was only kept for backward compatibility in case external projects used it, see #2180 (comment).
However, #2838 renamed the enclosing class, which already broke backward compatibility. Therefore it should be safe to remove the method now.

The method is not used within the Gson code and was only kept for backward
compatibility in case external projects used it.
However, 45e5e14 renamed the enclosing class,
which already broke backward compatibility. Therefore it should be safe to
remove the method now.
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!

I also wonder if we could just get rid of the GsonPreconditions class altogether. In each of the 9 places that use checkArgument, we could either have an explicit if+throw or a class-local checkArgument implementation. Otherwise I'm afraid we're going to end up with people referencing this class again, despite the internal in its name.

@eamonnmcmanus eamonnmcmanus merged commit 164ac9d into google:main Jul 15, 2025
11 checks passed
@Marcono1234 Marcono1234 deleted the patch-1 branch July 15, 2025 21:56
@Marcono1234
Copy link
Contributor Author

Have created #2879 to remove the GsonPreconditions class

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.

2 participants