Feature request: Kotlin optimization

[MukjepScarlet]

1. Some APIs will conflict in Kotlin.
   Example:

Long2ObjectMap.computeIfAbsent(long, V) <-> Long2ObjectMap.computeIfAbsent(java.lang.Long, V)

2. Kotlin built-in extensions will make many classes degenerate to normal type.
   Example:

Object2LongMap.forEach will produce entry with type java.lang.Object and java.lang.Long. And Map.put(K, V), etc.

Entry<K,V>.component1 / component2

One of the resolutions: PairExtensions.kt
I hope these stuffs could be library built-in ones, so Kotlin will give priority to existing member methods rather than extension functions

[vigna]

Well, I don't understand exactly what you're asking for here—note that I'm aware of Kotlin, but I have zero knowledge of the language...

[MukjepScarlet]

Well, I mean when you use this library in a Kotlin project, some frustrating conflicts will make the code more complicated.
In Kotlin we iterate a map like:

myMap.forEach { (key, value) ->
    ...something
} // key has type K and value has type V (Map.Entry<K,V>)

(componentN allow us to use destructuring expressions like var (key, value) = entry)

If myMap is an Int2ObjectOpenHashMap, and we don't want to let the key become an Integer, we have to:

myMap.int2ObjectEntrySet().forEach { entry ->
    val key = entry.intKey
    val value = entry.value
    ...something
}

So I hope the library can have built-in component1 and component2 functions for entries and pairs

[incaseoftrouble]

So to add that you would need public functions key_type component1() and value_type component2() on the Map.Entry?

[MukjepScarlet]

Yeah, but type-specified ones, like the int intValue() and maybe @Deprecated Integer value()

[incaseoftrouble]

Hmmm well that would pollute the autocompletion for all Java users. I think the better solution would be to provide a primitive variant of forEach (using appropriate BiConsumers). Something like forEachPrimitive(IntDoubleBiConsumer action) etc.

Not sure about your first point though, how they are conflicting ... these "conflicts" also exist in java, there they get resolved by type information.

[MukjepScarlet]

I think it might be better to create a "Kotlin module" of this lib like what Jackson does, providing extensions and utils.