Hi, everyone. I want to migrate some Java librarie...

# multiplatform

[刘zh]

Hi, everyone. I want to migrate some Java libraries to KMP, which use classes from java.util.concurrent. However, the kotlinx-atomicfu library only has atomic base classes and no collection classes like ConcurrentHashMap and ConcurrentLinkedQueue. Is there any other library that can do this?🙏🏻

[Vidmantas Kerbelis]

AFAIK this lib has some concurrent collections: https://github.com/touchlab/Stately (List, Map, Set)
Ktor also has ConccurrentMap and ConcurrentSet.
For LinkedQueue - no idea.

[Michael Paus]

The way to go are the Kotlin immutable collections. See:
https://github.com/Kotlin/kotlinx.collections.immutable

[刘zh]

This library seems to emphasize immutability rather than concurrency.

[Michael Paus]

Yes, it depends on your use-case whether that helps or not.

[Michael Krussel]

Stately goes with an actor model, so it won't have the performance of Java's concurrent library.

The ktor seemed interesting, but then the docs for it says.

Ktor concurrent map implementation. Please do not use it.

I would love to see a port of the concurrent data structures from Java ported into the standard lib.

[Michael Strasser]

Klogging library has a couple of hand-rolled classes that show you an approach using atomicFU:
• AtomicMutableList
• AtomicMutableMap

[AndrewStone]

I find that concurrent data structures end up being of limited use because applications often end up needing to atomically lock more than just that structure. And if you are locking in a larger context, its inefficient to lock just the structure. But for casual use and as dev begins, it is extremely irritating that these data structures don't protect their own state. It would be interesting to construct a library of data structures that take a mutex?=null during construction, and create their own mutex only if one is not supplied.

[Michael Krussel]

The concurrent collections in the Java library are designed to heavily reduce lock contention and perform way better than a single lock collection like what is returned from Collections.syncrhonizedMap.

But yeah, synchronized collections were typically not needed because you need the locking at a different level.