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
The original Java improvement project was Apache Commons Collections, and then of course Google Guava; both however never went as far as trying to redesign the Collections classes.
Have you checked out any of the many functional programming libraries out there? for example, Vavr and its List interface.
As for JSR: there is another idea I'm considering to submit to JCP. The idea is to implement support for variadic templates for Java. While working on Reactive Toolbox Core I've found that in many places such a functionality would significantly simplify code.
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.
The original Java improvement project was Apache Commons Collections, and then of course Google Guava; both however never went as far as trying to redesign the Collections classes.
Have you checked out any of the many functional programming libraries out there? for example, Vavr and its List interface.
Or, going up in abstraction, Arrow-kt's NonEmptyList or even Scala's Seq.
You may find there some good new ideas, and a validation of your approach.
I wasn't able to find any JSR on the topic, so if you build up something interesting, there may be space for that.
As for JSR: there is another idea I'm considering to submit to JCP. The idea is to implement support for variadic templates for Java. While working on Reactive Toolbox Core I've found that in many places such a functionality would significantly simplify code.
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.