Why the std-lib doesn't have a map implementation ...

# announcements

[Lulu]

Why the std-lib doesn't have a map implementation written in Kotlin, and instead uses platform-specific ones with expect/actual? Is performance the reason?

[Burkhard]

I guess it has a historic reason. On kotlin jvm only there is no reason to reinvent the wheel, so why not use the java stdlib classes when possible. I’m not sure what implementation backs kotlin js map, but kotlin native uses a custom map implementation. It’s here: https://github.com/JetBrains/kotlin-native/blob/master/runtime/src/main/kotlin/kotlin/collections/HashMap.kt

[Lulu]

I get that, but customizing maps would be nice so that could be one reason to have a common implementation

[E.Kisaragi]

I think for native is ok
since Java does jit-compile, so it avoids split impls and wont be jit-compiled.
also js has already Map (since 2015, but most browser - including IE11 partially - support it)

[eekboom]

If I am not mistaken Kotlin has to use the Java implementation for kotlin jvm for compatibility reason with existing Java code.

[mikehearn]

It's a performance optimisation. Java code tends to be more performance sensitive than JavaScript and the performance characteristics of the JVM are better known than V8. On the JVM calling a map function with an argument will often cause allocations, and Stream.map() goes megamorphic quite fast which means the indirections are slow. Historically C2 wasn't that great at fixing this situation (Graal is much better), so Kotlin has this inlined function trick. With JS I guess it's just assumed V8 will figure it out and if it doesn't, oh well, no big deal. If you care a lot about performance you aren't using browsers or NodeJS anyway <shrug>

[Joffrey]

@mikehearn I think the OP was talking about the Map interface, and e.g. Java's HashMap implementation. Not the map() function on collections.