eclipse / eclipse-collections

Eclipse Collections is a collections framework for Java with optimized data structures and a rich, functional and fluent API.
http://www.eclipse.org/collections
2.42k stars 604 forks source link

Why do primitive versions of interfaces do not implement java.util interfaces ? #1505

Closed pylvain closed 12 months ago

pylvain commented 12 months ago

Why for example, LongLongMap do not implements Map<Long,Long> ? It does make it harder to plug primitive versions in existing code. I'm not saying that is wrong, I'm just curious about the design choice behind.

Thank you 😄

mohrezaei commented 12 months ago

Implementing Map<Long,Long> would require constant wrapping/unwrapping. Eclipse collections targets scenarios that are garbage and memory sensitive. Constant wrapping/unwrapping can in some situations be even worse than just using fat Long objects.

Said differently, from the perspective of memory/garbage, if the code around this collection is using Longs, that's a serious code smell and we don't want to perpetuate that.

Additionally, Long can be null, which would require even more weird handling.

Handling memory/garbage with care is not a matter of "plugging" in a collection. It's a way of writing code that's literally more primitive.

motlin commented 12 months ago

I wrote more about this issue (pros/cons of easier boxing, and a potential solution) on this GitHub issue.

https://github.com/eclipse/eclipse-collections/issues/1408

On Thu, Sep 7, 2023 at 7:30 PM Mohammad Rezaei @.***> wrote:

Implementing Map<Long,Long> would require constant wrapping/unwrapping. Eclipse collections targets scenarios that are garbage and memory sensitive. Constant wrapping/unwrapping can in some situations be even worse than just using fat Long objects.

Said differently, from the perspective of memory/garbage, if the code around this collection is using Longs, that's a serious code smell and we don't want to perpetuate that.

Additionally, Long can be null, which would require even more weird handling.

Handling memory/garbage with care is not a matter of "plugging" in a collection. It's a way of writing code that's literally more primitive.

— Reply to this email directly, view it on GitHub https://github.com/eclipse/eclipse-collections/issues/1505#issuecomment-1710885042, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3UISGGC37YKF7BKS4VUDXZJKKNANCNFSM6AAAAAA4PM4OWI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

pylvain commented 12 months ago

Ok that makes absolute sense. I use Kotlin, and from this perspective, it's a little bit weird :

class LongReturner {
    fun getLong(): Long = -1L
}

Here, looking at the bytecode, no boxing will occur. But :

interface Foo<T> {
    fun getLong (): T
}

class LongReturner: Foo<Long> {
    override fun getLong(): Long = -1L
}

Here boxing occur now.

Thank you for your quick replies anyway 😄