Skip to content
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

Closed
digitalbuddha opened this issue Dec 29, 2019 · 12 comments
Closed

Create kotlin multiplatform targets #50

digitalbuddha opened this issue Dec 29, 2019 · 12 comments
Labels
External Contribution Welcome We will accept and be grateful for someone to pick this issue up

Comments

@digitalbuddha
Copy link
Contributor

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

@ankushg
Copy link

ankushg commented Jan 20, 2020

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

@digitalbuddha
Copy link
Contributor Author

We are all pretty green when it comes to multiplatform. Feel free to take this on and let us know how it goes!

@eyalgu eyalgu added the External Contribution Welcome We will accept and be grateful for someone to pick this issue up label Jan 28, 2020
@clhols
Copy link
Contributor

clhols commented Mar 6, 2020

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.
But Duration is experimental and it does change the API.
But it will be nice from Kotlin:
fun expireAfterWrite(duration: Duration): 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.

@ychescale9
Copy link
Contributor

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?

@digitalbuddha
Copy link
Contributor Author

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!

@ychescale9
Copy link
Contributor

Great, I'll create an issue and start working on kotlin.time migration.

@clhols
Copy link
Contributor

clhols commented Mar 7, 2020

I did try kotlin.time on the Cache and tests yesterday, so I can create a PR with those changes.

@ychescale9
Copy link
Contributor

@clhols sure!

@riclage
Copy link

riclage commented Jun 19, 2020

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.

@digitalbuddha
Copy link
Contributor Author

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:
Truth test constructs need to be migrated
Channels/actors do not work.

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

@9468305
Copy link

9468305 commented Jun 5, 2021

Channels/actors pattern can be replaced by kotlin coroutines MutableSharedFlow/MutableStateFlow now, which support mutable data transfer cross coroutines/threads.

@matt-ramotar
Copy link
Collaborator

Closing as #493 added support for iOS, JVM, and JS!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
External Contribution Welcome We will accept and be grateful for someone to pick this issue up
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants