From https://www.eclipse.org/collections/
History of Eclipse Collections
The origin of Eclipse Collections was
started off as a collections framework named Caramel at Goldman Sachs
in 2004. Since then the framework has evolved, and in 2012, it was
open sourced to GitHub as a project called GS Collections.
GS Collections has been presented at number of conferences including
JVM Summit in 2012 and JavaOne in 2014. A performance comparison
between the parallel lazy implementations of Java 8, Scala and GS
Collections was presented at QCon New York in 2014. Also articles
about GS Collections (Part1 / Part2) have published on InfoQ.com
showing some of the capabilities of the collections framework through
examples, and also interviews to the creator of GS Collections.
Over the years, around 40 or so developers from the same company have
contributed to the collections framework.
To maximize the best nature of open source project, GS Collections has
been migrated to the Eclipse Foundation, re-branded as Eclipse
Collections in 2015. Now the framework is fully open to the community,
accepting contributions!
It seems it still alive. And if you read the above page it's fully operational with java 8 lambda's.
boolean anyPeopleHaveCats =
this.people
.anySatisfy(person -> person.hasPet(PetType.CAT));
boolean anyPeopleHaveCats =
this.people
.stream()
.anyMatch(person -> person.hasPet(PetType.CAT));
When you look at the repository at https://github.com/eclipse/eclipse-collections you can see that there are still contributions made and merged into it.
So I would say it's not deprecated, but an extra feature of ready to use methods you can use with your own code and java streams to make streaming a bit easier.
It still adds easy comparator functions etc.. so you don't have to write your own, you can just implement a ready to use lamda method or stream parser that suit your needs. It does seem superfluous, because anySatisfy seems a lot like filter, but it does add a lot of clarity to the code by writing out what exactly is expected to happen in the code itself.
The stacks and Bags seem useful to me under certain circumstances. And sometimes you don't want to use streams because it's a small collection(1000 or less), making the overhead of streams initialization is not worth it.
And this makes it a lot easier to write smaller code that performs better.
It might not be as useful essential as before java8, but there is still a place for it.