Also, I did read several articles which compare different implementations. One of them shows that GS Collections significantly more efficient in regard to memory and performance than Scala implementation. Sorry, have no link on that article handy.
Unfortunately most of mentioned above implementations do not try to rethink Java Collections interfaces completely.
The idea is to prepare API convenient for everyday use, rather than based on any theoretical considerations or paradigms.
Most inspiration for the API above I've obtained from Kotlin and some extension functions written by my colleagues for one of the projects I've recently worked on. As far as I can tell, this API covers vast majority of use cases I see in code.
One note: I think that java.util.List (as well as other collections) API stopped changing because of addition of stream() method. Streams are really powerful and convenient, so most (if not all) use cases can be covered with them. There are two drawbacks though:
bridge to Streams caused stall in JCF API evolution (recent addition of factory methods basically changes nothing in List/Set/Map API's)
there is some extra verbosity which pollutes code with unnecessary noise (.stream()...collect()).
Passionate developer in Java and Scala. And sometimes, something else. A few months per year, someone calls me "professor". CoFounder of Scala By The Lagoon @scalagoon
Cool, didn't know about the Capsule library. Oh, and the Scala library is not optimized for primitive type efficiency like the GS one, so the benchmark result is not surprising 😁
Is your idea about introducing a better API, a more explicit (and probably better) performance footprint, or are you aiming at both with one stone?
I've decided to start with API and implement it in very simple and straightforward way. Later I'm going to write better performing implementation while keeping API intact. Trying to do both things together is not the best approach since changes in API will be much harder to adopt and maintain.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the suggestion.
In my practice I've used Apache Commons and Guava. I've also looked into several other collections implementations, in particular Efficient Immutable/Persistent Collections for Java, GS Collections (now Eclipse Collections) and The Capsule Hash Trie Collections Library. Last one lacks List, but contains efficient implementations of Set and Map.
Also, I did read several articles which compare different implementations. One of them shows that GS Collections significantly more efficient in regard to memory and performance than Scala implementation. Sorry, have no link on that article handy.
Unfortunately most of mentioned above implementations do not try to rethink Java Collections interfaces completely.
The idea is to prepare API convenient for everyday use, rather than based on any theoretical considerations or paradigms.
Most inspiration for the API above I've obtained from Kotlin and some extension functions written by my colleagues for one of the projects I've recently worked on. As far as I can tell, this API covers vast majority of use cases I see in code.
One note: I think that
java.util.List(as well as other collections) API stopped changing because of addition ofstream()method. Streams are really powerful and convenient, so most (if not all) use cases can be covered with them. There are two drawbacks though:.stream()...collect()).Cool, didn't know about the Capsule library. Oh, and the Scala library is not optimized for primitive type efficiency like the GS one, so the benchmark result is not surprising 😁
Is your idea about introducing a better API, a more explicit (and probably better) performance footprint, or are you aiming at both with one stone?
I've decided to start with API and implement it in very simple and straightforward way. Later I'm going to write better performing implementation while keeping API intact. Trying to do both things together is not the best approach since changes in API will be much harder to adopt and maintain.