Maintenance status

[raiju]

I've been working on a larger PR to improve the S/N ratio a bit to make it practical to use. The two main changes are:

• Track whether field access/method calls are to static fields/methods
• The reachability graph only goes through methods that were actually called (as opposed to adding the full class if one method was called)

Additionally I implemented a gradle-plugin to make it more useful for my projects.

I've tested this both with local tests & on a real project with satisfactory results. Before I go on and start cleaning up the PR (mainly will need to do some research into Maven; usually use Gradle myself), is there still interest to review/maintain this plugin here? If yes, does Spotify have a public-facing style-guide I can adhere to for this PR?

[spkrka]

That sounds great! We have not spent much time on this recently, but we still use it sometimes, and we'll happily review/merge PRs. As for style-guide, we're mostly using the https://google.github.io/styleguide/javaguide.html (with minor tweaks) so that should be good enough.

(If the PR is reasonably formatted and useful I'd rather merge it and fix up the style myself if necessary rather than miss out on it completely)

I have also had plans on improving the reachability analysis, but found it tricky when there could be reflection involved, and callbacks into your code from third party code.

[raiju]

Sweet, posted the PR. It's a bit of a monster (left out the gradle piece for now), but hope it's useful enough to make it useful to merge. That said, the PR makes no attempt at tackling the reflection problem 😉

[alecl]

@raiju would you consider releasing your fork with gradle support? I'd be interested in checking it out.

[bmarcaur]

Hey @raiju et al!

I had no idea that @raiju worked on this despite being at the same company. Whoops.

No matter though, we ended up "spiritually forking" this repository (after talking with a former owner). You can find it here https://github.com/palantir/gradle-transitive-abi-checker. The previous owner told us that one of the reasons they didn't adopt it at at Spotify was due to the performance penalty of adding this to every build. So we worked to drastically reduce the runtime and memory overhead. We also added detection for more types of ABI breaks. And we also added a Gradle plugin since that is the build infrastructure we rely on.

We also dropped the maven plugin since we don't use that internally, but we preserved the separation of Gradle and detection logic while leaving most of the library ABI unchanged. Meaning it would be trivial to fork the current maven plugin and swap over to our maven coordinate.

We rolled this out internally to over 500+ of our repositories. Spanning 10's of millions of lines of code and 10's of thousands of transitive dependencies. It runs on every ./gradlew check build both locally and on CI. The perceived performance penalty is either essentially zero (done in parallel with a longer task), or is so low that its imperceptible. The most interesting aspect of rolling it out was actually getting the PR's to merge. Which was difficult due to ABI incompatibilities already existing on develop (nice to find, but oof). However, the effort to merge them across our fleet was well worth it IMO as we are now starting to evolve our libraries in ways we could not before due to the enhanced safety provided by this tool.

Anyways, its been 5+ years since the last comment, but maybe someone finds this or you are still in need somewhere out there.