我最近偶然发现了 Eclipse Collections,它们看起来棒极了——几乎和 Java 8 流看起来一样棒。我通读了一些介绍、演示文稿和教程,似乎 EC 添加的几乎所有内容,现在都可以使用流来完成。
没有任何贬低 EC 的意思,既然我们有流,图书馆是否还有任何价值,这可能在我读到的内容中被掩盖了?还是它本质上走的是乔达时代的道路?如此之好以至于它几乎一字不差地被采用到 Java 中,从而否定了对库的需求?
我最近偶然发现了 Eclipse Collections,它们看起来棒极了——几乎和 Java 8 流看起来一样棒。我通读了一些介绍、演示文稿和教程,似乎 EC 添加的几乎所有内容,现在都可以使用流来完成。
没有任何贬低 EC 的意思,既然我们有流,图书馆是否还有任何价值,这可能在我读到的内容中被掩盖了?还是它本质上走的是乔达时代的道路?如此之好以至于它几乎一字不差地被采用到 Java 中,从而否定了对库的需求?
来自https://www.eclipse.org/collections/
Eclipse Collections 的历史 Eclipse Collections
的起源始于 2004 年高盛的一个名为 Caramel 的集合框架。从那时起,该框架不断发展,并于 2012 年作为一个名为 GS Collections 的项目向 GitHub 开源。GS Collections 已在包括 2012 年的 JVM 峰会和 2014 年的 JavaOne 在内的许多会议上进行了介绍。Java 8、Scala 和 GS Collections 的并行惰性实现之间的性能比较在 2014 年的 QCon New York 上进行了介绍。还有关于 GS Collections 的文章(第 1 部分 / 第 2 部分)已在 InfoQ.com 上发布,通过示例展示了集合框架的一些功能,并采访了 GS Collections 的创建者。
多年来,来自同一家公司的大约 40 名开发人员为集合框架做出了贡献。
为了最大限度地发挥开源项目的最佳性质,GS Collections 已迁移到 Eclipse 基金会,并于 2015 年更名为 Eclipse Collections。现在该框架已向社区完全开放,接受贡献!
它似乎还活着。如果您阅读了上面的页面,它可以完全使用 java 8 lambda。
boolean anyPeopleHaveCats =
this.people
.anySatisfy(person -> person.hasPet(PetType.CAT));
boolean anyPeopleHaveCats =
this.people
.stream()
.anyMatch(person -> person.hasPet(PetType.CAT));
当您查看位于https://github.com/eclipse/eclipse-collections的存储库时,您可以看到仍然有贡献并合并到其中。
所以我想说它并没有被弃用,而是一个额外的即用型方法,您可以使用自己的代码和 java 流来简化流式传输。
它仍然添加了简单的比较器功能等。所以您不必编写自己的,您可以实现一个现成的 lamda 方法或适合您需要的流解析器。它看起来确实是多余的,因为 anySatisfy 看起来很像过滤器,但它确实通过写出代码本身预期发生的确切情况为代码增加了很多清晰度。
在某些情况下,堆栈和包对我来说似乎很有用。有时你不想使用流,因为它是一个小集合(1000 或更少),使得流初始化的开销是不值得的。这使得编写性能更好的更小代码变得容易得多。
它可能不像以前的 java8 那样有用,但仍有一席之地。