Transitive dependency on new, problematic Guava version

[lepistone]

Hi!
Our organization is large: we have a few thousand Maven projects plus a Bazel repo, all importing an internal BOM which in turn imports Google's libraries-bom. Many libraries of course depend on error-prone-annotations, and we also have a few internal checks that import -core.

The latest error-prone 2.38.0 upgraded to Guava 33.4.6, part of a series of releases that introduce a few problems. In practice, the changes with modularization and nullability checks means that many projects don't build with the upgrade and require some time to fix.

We had a very similar situation a few months ago where error-prone upgraded protobuf to a release that is known to introduce complicated breaking changes that can take a long time to fix.

Since in Maven, transitive dependencies are intended as minimum requirements, and in fact to avoid problems we run the enforcer-plugin with the requireUpperBounds check, when a widely used tool like error-prone upgrades to very recent and problematic releases of libraries like protobuf and guava, large organizations especially can have problems.

Specifically for Guava in this case, was this upgrade really necessary or could it be reverted? Maybe error-prone could have a policy to be very conservative in the transitive dependencies that it introduces to relieve such problems? That would help a lot, thank you!

As a side note, is there an expectation that an organization uses all the different error-prone libraries (-annotations, -core, etc) at the same version - and in that case, could you consider an internal BOM to facilitate that? Or instead do you see them more as separate, where general usage of the annotations should only depend on the latest error-prone-annotations (which doesn't pull anything transitively), and only custom defined checks should pull the other libraries, including their more problematic transitive dependencies? Thanks again!

[cpovirk]

(I am only an occasional contributor to Error Prone, but I am the cause of your problems on the Guava side, so hi :))

I gather that there are at least two things going on:

• Adding nullness information and/or a module-info can require changes in users.
• 33.4.6 had an outright bug in its module setup (and a couple other bugs that affected Android and the optimizers commonly used for it).

The latter problem could be solved by upgrading Error Prone to 33.4.8. (And users could also upgrade manually.) I think that moving Error Prone from Guava 33.4.6 to Guava 33.4.8 would be a strict improvement. But.

The former problem doesn't normally have such an easy solution: Users just need to adapt to the nullness information and module-info. So this is an argument for jumping back to 33.4.0, which pre-dates all the nullness changes.

I don't want to speak for the actual Error Prone team, but I imagine that, in general, they'd like to be on the newest version of Guava: That ensures that they're running their open-source build against a version of Guava that's as close as possible to the one that they're using inside Google. That said, Guava sometimes goes a while without publishing a release, and I suspect that that causes trouble for Error Prone only occasionally. Additionally, since all the recent releases of Guava have intentionally been only patch releases, there is no need to upgrade to pick up any new APIs. (This will change eventually, of course.) So it should be very likely to be safe to drop back to 33.4.0. (And Error Prone itself is unlikely to care much about depending on a version of Guava with nullness information, module-info, or even migration off sun.misc.Unsafe (since most of our usages of that are in concurrent code that I'm guessing that Error Prone doesn't use).)

(Incidentally, if you've found anything interesting or surprising about the challenges of upgrading Guava, I'd be interested in hearing about it. We've known that the nullness annotations are potential trouble, mainly for Kotlin and NullAway, but we made enough other changes that could affect enough other people that I'm sure that's not all that's come up.)

[cushon]

in general, they'd like to be on the newest version of Guava

This is generally how I was thinking about it. I can try to publish a new release of EP that updates the Guava version soon.

Error Prone should generally be extremely compatible with different Guava versions, so if users wanted to override the Guava version with a newer or slightly older one that would probably also work fine in practice. Would that be compatible with the requirements here, or is it necessary to be using Error Prone with the exact Guava version it specifies in its pom?

[cushon]

I cut a release that downgrades to Guava 33.4.0: https://github.com/google/error-prone/releases/tag/v2.39.0