Check for binary compatibility during Maven (or CI) build

[Marcono1234]

Problem solved by the feature

As seen in #2169 (comment), one can easily by accident break binary backward compatibility, for example by changing the return type of a method.

Feature description

Either as part of a regular Maven build, or at least triggered by the CI, a check for binary compatibility should be performed.
Breaking changes should either cause an error or at least a warning, ideally with GitHub annotation for the code causing the issue. Optionally it might be useful to also generate a report which can be obtained as GitHub workflow artifact, showing the binary API differences. This could be useful to detect accidentially exposed methods or fields.

It appears there are multiple tools and Maven plugins for this; some of them are:

• https://github.com/siom79/japicmp
• https://github.com/revapi/revapi

Alternatives / workarounds

Do nothing and review pull requests thoroughly to not break binary compatibility by accident?

[eamonnmcmanus]

Seems like a great idea if someone wants to implement it!

We check Gson-at-head against all of Google's internal tests fairly often, and certainly before releasing new versions, but that would not generally catch this sort of problem. Everything is rebuilt from source in our monorepo, both Gson itself and its clients, so a change that is source-compatible but not binary-compatible could go unnoticed. We would only find out after making a release and getting complaints.