-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create kotlin multiplatform targets #50
Comments
Is this something that external contributions would be accepted for? I’m definitely interested in exploring this, but want to be sure that it’s not something y’all have an internal plan for already |
We are all pretty green when it comes to multiplatform. Feel free to take this on and let us know how it goes! |
I guess the first step is to start using the Kotlin equivalent of the Java libs. E.g. java.util.concurrent.TimeUnit can be replaced with kotlin.time.Duration in Cache.Builder. You can also start using org.jetbrains.kotlin:kotlin-test instead of Junit and Truth. Then it gets harder when it comes to file IO and concurrency. |
I thought about using kotlin.time while rewriting the cache but was a bit concerned with forcing the experimental APIs on consumers. I can take another look at this if people are not too concerned with using more experimental APIs which we’re already doing. Also should we work on a separate branch for the KMP effort? |
Since we are in alpha I am comfortable depending on kotlin.time apis. We can move quickly if there is a critical issue or mark our code as experimental as well. multiplatform branch sounds good! |
Great, I'll create an issue and start working on |
I did try kotlin.time on the Cache and tests yesterday, so I can create a PR with those changes. |
@clhols sure! |
Hi, is there an update or roadmap on the kotlin multiplatform effort? Curious to know where this project stands and what are the ways I can help. |
Hello! At this time we are putting a pause on the multi platform efforts until we can hit stable. We are working through the last bug prior to beta. Some of the current concerns with kotlin native: The first is easier to fix but the 2nd is rather complex. Our architecture is very much based on having primitives that allow a multi threaded actor impl. My hope is to pick this work up again once concurrency in kmp improves |
Channels/actors pattern can be replaced by kotlin coroutines MutableSharedFlow/MutableStateFlow now, which support mutable data transfer cross coroutines/threads. |
Closing as #493 added support for iOS, JVM, and JS! |
Once #49 lands we will be 100% kotlin. Next, we should create kotlin multiplatform targets and explore current solutions for handling flow/suspend within native/js
The text was updated successfully, but these errors were encountered: