I love the google-collections library. It’s got some really nice features. But, it’s not stable yet. They’ve explicitly stated that until they hit 1.0 it’s not going to be a stable API. So there are changes each release. Nothing major, but changes.
As an example, in the jump from 0.9 to 1.0rc1, the static methods on the Join class became the fluent API on the Joiner class.
(as an aside, could we have some tags, please?)
Following this change is simple.
@@ -310,7 +310,7 @@ } catch (KeyStoreException e) { throw new RuntimeException(e); } - return Join.join(" | ", principals); + return Joiner.on(" | ").join(principals); } /**
But the knock-on effect comes when you start getting lots of things which have google-collections dependencies. At $WORK
, I’ve got a project whose dependencies look like this.

I wanted to extract a part of DC2 into its own library, commslib
. This was pretty easy as the code was self contained. Naturally, I wanted it to use the latest version of everything, so I upgraded google-collections to 1.0rc1. Again, fairly simple.
This is what I ended up with.

Except that now there’s a problem.
- commslib uses
Joiner
, so it’ll blow up unless it upgradeDC2
‘s google-collections to 1.0rc1. - GSK uses
Join
, so it’ll blow up if I upgradeDC2
‘s google-collections to 1.0rc1.
And thus have I painted myself into a corner. 🙂
As it happens, DC2
had a dependencyManagement section forcing everything to use google-collections 0.8. → Instant BOOM.
The solution is to upgrade all my dependencies to use google-collections 1.0rc1. But this turns out to be a much larger change than I had originally envisaged, as now I have to create releases for two dependent projects. This isn’t too much of a hassle in this case (yay for the maven-release-plugin), but it could be a large undertaking if either of those projects is not presently in a releasable state.
I’m not trying to pick on google-collections (I still love it). I’m just marvelling at how quickly complexity can blossom from something so simple.