Refactoring to Eclipse Collections: Making Your Java Streams Leaner, Meaner, and Cleaner
It looks much faster than jdk streams
JMH Benchmark Results
I would like to see Eclipse Collections support in Kotlin, especially after Java EE development was moved from Oracle to Eclipse Foundation.
What do you mean by support? You can use them as is without any additional changes to the language. Just load appropriate library and work with it. I would even look better because cleaner lambda syntax.
And I don’t understand what it has to do with Java EE.
Sure, I can leverage any java lib with Kotlin.
Kotlin has it’s own collection interfaces like List, Map, … and the set of extension functions like public fun <T> listOf(element: T): List<T> = java.util.Collections.singletonList(element).
I mean to have another implementaion of extension functions, that are based on Eclipse collections and support Kotlin specific interfaces. Hence, I will be able just to replace Maven/Gradle dependency and have under the hood Eclipse collections instead of jdk ones. SOLID (Dependency inversion principle) 
There are rather many different collection frameworks and there is sense to have Kotlin specific support only for core ones. I consider former Java EE (now Jakarta EE supported by Eclipse Foundation) as core framework. I think, that (possible I am not right), that Eclipse collections become part of Jakarta EE.
I think it is a bad idea to just implicitly replace something so that behavior changes without notice. If you are keen on not modifying the code, you can define new global function in your own module that shadows default kotlin global methods. As far as I remember, it should work, but I would still propose to create a factory object, say Eclipse and produce collection instances from it like Eclipse.listOf(..,) to avoid confusion.
I agree. Often, this is indeed the case.
Please submit a feature request here: http://kotl.in/issue
