Kotlin multiplatform support?

[dylanenabled]

Are there any plans for a port of the automerge bindings to kotlin multiplatform so that the one codebase can target iOS, Android, JVM and Browser?

It's probably possible by implementing the business logic and calling out to one of the existing libraries to implement the transactions, or wrapping the rust code on each platform directly, but having an official multiplatform library would be great.

I'd be willing to help out of it's on the roadmap.

Please let me know if this isn't the appropriate place for this sort of question.

[alexjg]

I would be very interested in such a project! I haven't much time to work on this myself but very happy to discuss designs and review code.

[ptitjes]

I am also interested on working on a Kotlin multiplatform version of Automerge. I tried wrapping automerge-java using expect/actual declarations, however in its current form automerge-java is highly dependant of the Java standard library (mainly around the uses of Optional, and similar) and therefore not very much Kotlin-idiomatic.

I see two way around this:

• Extract the raw Rust AutomergeSys JNI binding in a separate library, modify it current implementation to remove the Optional, and do the Optional wrapping in the Java code directly. Then we could directly use these raw bindings in a new automerge-kotlin.
• Duplicate and adapt your current Rust/JNI code for the JVM part of a new multiplatform automerge-kotlin. But that would duplicate the maintenance effort.

I am not Rust-proficient but I would happily start such a project.

FYI, I started an implementation of automerge-repo. It is only targeting the JVM for now but mainly uses multiplatform stuff, so that it would easily be made multiplatform.

What do you all think?

[alexjg]

Hmm. I would like to make sure that automerge-java is - as far as possible - pleasant to use for actual Java programmers. A kotlin multiplatform library will require some kind of kotlin wrapper anyway in order to handle platforms which are not supported by the JNI based library. On that basis I think we should probably go for your first option.

Re. automerge-repo, I have a half finished kotlin implementation sitting aorund somewhere. I'll try and clean it up a bit and publish it somewhere for you to take a look at.