Just a bit of clarification, as Vladimir is a bit bending things: Guava devs said this: "This might have made sense to do in the original release. (And I have to imagine that we didn't even think of the CVE angle at that point.) After that point, though, it became a recipe for conflicts between some version of the main guava artifact and some other version of a package like guava-base. We could reconsider someday if the ecosystem were to have better support for splitting up artifacts in the future.
Another part of our story has been that most users' needs don't follow clean package lines. Maybe they want just an implementation of BiMap, but they still get all of collect (and its dependencies (annotations, base, math, primitives). People who want to optimize for binary size are going to get better results from custom shading/minimization. Historically, we also worried that Maven users would end up with, say, guava-base:10.0.0 but guava-collect:20.0.0, and then they'd have problems because collect depends on base features that we added later. This is of course a much more general problem that is best solved with Dependabot / requireUpperBoundDeps / Gradle / whatever, but it was particularly acute back when Guava was adding features rapidly and the ecosystem was less developed in how it handled dependency hygiene. (Also, as everyone knows, Guava was also removing APIs, creating potential trouble in the other direction.) Oh, and it used to be that more people were manually downloading jars, too! So extra jars actually increased friction. [edit: We've also considered that we might someday want to allow circular dependencies between packages, but I'm not convinced that will ever happen.] Anyway, those concerns are all gone or at least reduce nowadays. (Compare also the complaints we've gotten about our listenablefuture and failureaccess jars, which normally "just worked" but have which ended up causing significant trouble in some cases. Those are of course not the specific kind of change you're suggesting here; I just offer them as examples of how any extra bit of complexity in our build setup will end up causing problems, both foreseen and unforeseen.) There are some past discussions of this that I (or someone else) might manage to dig up later, but I think that's the short answer: It was arguably the right decision years ago, but at this point, any change to our dependency structure seems likely to create more problems than it solves." Then Vladimir wrote this: "Do you mean the key culprit is Maven’s inability to deal with old guava:20 and new guava-hash:42 being present both in the dependency tree?" Which was confirmed by Guava devs by "Right". But there is much more to it, as Guava devs added a great deal of explanation of other aspects too (and history bits). Just saying, to have this on the list too, for "those who find it in the search". Thanks T On Tue, Nov 4, 2025 at 9:45 PM Vladimir Sitnikov <[email protected]> wrote: > > Here's one more data point. > > Guava developers say "Maven's inability to deal with old guava:20 and new > guava-hash:42 being present both in the dependency tree" is > a showstopper for splitting Guava into several modules. End-users requested > the split multiple times for the past decade. > > See https://github.com/google/guava/issues/8079#issuecomment-3487896211 > > So the issue is real. Maven could do much better. > > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
