常见问题: 谷歌集合FAQ

Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead? The Apache Commons Collections very clearly did not meet our needs. It does not use generics, which is a problem for us as we hate to get compilation warnings from our code. It has also been in a "holding pattern" for a long time. We could see that it would require a pretty major investment from us to fix it up until we were happy to use it, and in the meantime, our own library was already growing organically. An important difference between the Apache library and ours is that our collections very faithfully adhere to the contracts specified by the JDK interfaces they implement. If you review the Apache documentation, you'll find countless examples of violations. They deserve credit for pointing these out so clearly, but still, deviating from standard collection behavior is risky! You must be careful what you do with such a collection; bugs are always just waiting to happen. Our collections are fully generified and never violate their contracts (with isolated exceptions, where JDK implementations have set a strong precedent for acceptable violations). This means you can pass one of our collections to any method that expects a Collection and feel pretty confident that things will work exactly as they should.

在我看来，更好的选择是番石榴(原名谷歌系列):

它更现代(有泛型) 它完全遵循集合API的要求 它被积极地维护着 CacheBuilder和它的前身MapMaker都非常棒

Apache Commons Collections也是一个很好的库，但它一直未能提供支持泛型的版本(在我看来，这是集合API的一个主要缺点)，并且通常似乎处于维护/不做太多工作的模式，最近Commons Collections再次获得了一些动力，但它还有一些追赶的工作要做。

如果下载大小/内存占用/代码大小是一个问题，那么Apache Commons Collections可能是一个更好的候选，因为它是其他库的一个常见依赖项。因此，在您自己的代码中也可以使用它，而无需添加任何额外的依赖项。编辑:这个特殊的“优势”现在已经部分被颠覆了，因为许多新的库实际上依赖于Guava，而不是Apache Commons Collections。

关于Guava的一个讨厌的事情是Multimap没有扩展java.util.Map。如果你有自己的方法在地图上工作，他们不会在Guava MultiMap上工作(Apache MultiMap接口确实扩展了java.util.Map)。我相信有一些很好的理由，为什么它是这样，但它也不方便。

我发现最重要的事情，使谷歌集合的地方开始:

泛型(没有泛型的集合——FTL) 与Collections框架的一致性(Josh Bloch是该框架的关键参与者) 的正确性。这些人迫切地想要解决这个问题;他们有类似25K个单元测试的东西，并且与获得正确的API紧密相关。

这是一个很棒的Youtube视频，是主要作者的演讲，他很好地讨论了关于这个库值得了解的内容。

另外两件事(我希望我没有错)

Guava(谷歌集合的新名称)的许可证是Apache许可证2.0，意思是:与Apache Commons项目相同 我在文件中找不到Guava的源代码来下载(似乎只有git-access是可能的)

常见问题: 谷歌集合FAQ

Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead? The Apache Commons Collections very clearly did not meet our needs. It does not use generics, which is a problem for us as we hate to get compilation warnings from our code. It has also been in a "holding pattern" for a long time. We could see that it would require a pretty major investment from us to fix it up until we were happy to use it, and in the meantime, our own library was already growing organically. An important difference between the Apache library and ours is that our collections very faithfully adhere to the contracts specified by the JDK interfaces they implement. If you review the Apache documentation, you'll find countless examples of violations. They deserve credit for pointing these out so clearly, but still, deviating from standard collection behavior is risky! You must be careful what you do with such a collection; bugs are always just waiting to happen. Our collections are fully generified and never violate their contracts (with isolated exceptions, where JDK implementations have set a strong precedent for acceptable violations). This means you can pass one of our collections to any method that expects a Collection and feel pretty confident that things will work exactly as they should.