Hey everyone! Several months ago I’ve already show...

# multiplatform

[Oleg Yukhnevich]

Hey everyone! Several months ago I’ve already showed some POC of FFI for KMP here: https://kotlinlang.slack.com/archives/C0BJ0GTE2/p1677748948814649
But now I want to ask for your help to understand some requirements/ideas, as now Im trying to make it possible to everyone to try it via making gradle plugin! (still highly experimental)

To remind: I am currently doing (more or less successfully) something similar to cinterop but for kotlin multiplatform (jvm, android, native, js, wasm - now more focus on jvm, android and native iOS+linux)
There are a lot of questions about how to integrate everything in gradle plugin, but this is all solvable and just need time

But I wanted to just ask some questions about the final runtime API itself:
1. is there something you do/don’t like in kotlinx.cinterop?
2. is there something you do/don’t like in other solutions for FFI like JNA, JNI, etc (any language is ok)?
3. what features are required, without which it makes no sense to have FFI in Kotlin?
4. what tasks could be solved at you side if there was FFI in KMP?
5. what would you like to have, what is missing in other tools?
6. what good examples of FFI in other languages can you suggest where to look for ideas? (I have already looked at a lot of things, but may be I haven’t found something)
7. anything else I need to know to make FFI users in kotlin multiplatform happy? 🙂
(if there are any tips on how to collect some kind of stats/openions, I will be glad to hear it, you can DM me)

[Adam S]

3 - I'd like kotlin-ffi to (eventually) to support all Kotlin targets

4 - I'd like to solve the problem of 'Regex is different on every platform' KT-49557 by writing a multiplatform wrapper around the C pcre2 library

7 - be compatible with Gradle Build & Config Cache

any tips on how to collect some kind of stats/openions

Perhaps make a GitHub issue in the project, with your list of questions. Under each question, add summaries of the responses you get, along with a link.

[Oleg Yukhnevich]

First, thx for the feedback!
3. my POC already supports all targets, but there are some issues with in JS/Wasm: both from distribution side and from runtime side (wasm can have multiple memories attached, and so need to think more carefully on how to interact with them)
4. nice!
7. yeah, I’m trying to follow best practices… But may be on initial release not everything will work here, there are too much of moving parts 🙂

Perhaps make a GitHub issue in the project

Totally forgot, that GitHub now has also Discussions… I think, that should work better for such discussion without direct action points. Thx! I will prepare something there in coming days

[Adam S]

GitHub issues also have tasklists which might be nice :) https://docs.github.com/en/issues/managing-your-tasks-with-tasklists/creating-a-tasklist

[Michael Paus]

6. https://mozilla.github.io/uniffi-rs/

[Michael Paus]

7. Kotlin has its roots in the Java world and so it is no wonder that there are projects which use lots of proprietary, open source or even commercial Java libraries. As long as you are running your Kotlin code on a JVM (or Android) this is no problem because the integration of Java into Kotlin is more or less seamless. But as soon as you go multiplatform you completely loose this smooth access to this ecosystem. Actually this was one of the main reasons to drop iOS support in almost all of my compose multiplatform projects. What I am hoping for is some solution to carry over my java libraries to Kotlin multiplatform as easily as it is possible on the JVM.
GraalVM/native-image might be of great help here. It already has the ability to compile one or more Java libraries into a platform specific shared library and automatically create JNI compatible API methods inside it. Such a shared library can then be directly used from Java (or Kotlin) on a JVM. What is now needed is some way to tell Kotlin to also use this JNI API when it is compiled for some native platform in order to get back this smooth integration between Kotlin and Java.

[Oleg Yukhnevich]

Thx!
That’s much harder, and while it should be possible - by parsing C headers used for JNI and generate something from it
But not sure, that’s really needed here
If there are a lot of JNI in a project, there will be a lot more other JDK related things, that will be hard to map right away to KMP
So, I don’t think, that something like this will appear in near future
I will go in this case with rewriting those parts manually, if someone will want to go with KMP FFI

[Adam S]

1. something I'd like improved in kotlinx.cinterop: I'd like to hide the generated bindings from library consumers.

I really like that Kotlin generates bindings for C code, but if I'm writing a library I usually want to hide the generated wrappers from users. This is because the bindings are often confusing to use, they might change without notice (due to changes in the underlying C library), and I usually write my own bindings and I don't want users to confuse the generated bindings with my own. I think the best solution would be to add an opt-in annotation on the generated bindings https://youtrack.jetbrains.com/issue/KT-56226/

[Oleg Yukhnevich]

Yeah, you are right! That’s also something that I suffer from in cryptography-kotlin, where there is no way to hide implementation details
At my side, Im now experimenting with allowing to make some declarations internal or adding specified optIn there!

[Adam S]

5. Something I'd really like to have is for the ffi-generator to generate C wrappers for a C++ code.

For example, I'd like to use RocksDB and Jolt (a C++ physics engine) in Kotlin/Native, and writing C wrappers is something far too complicated for me to do manually, so I'm dependent on someone (zig-gamedev) writing custom C wrappers, which doesn't usually cover a lot of code, or can be out-of-date.

I expect that this will be a complicated task, but it seems that rust-bindgen has limited support? https://rust-lang.github.io/rust-bindgen/cpp.html. Any C-wrappers would probably not need to be comprehensive - just the high-level functions and responses.

[Adam S]

1. something I'd like improved in kotlinx.cinterop: it's difficult to view the generated source code, and comments from the source bindings.

It would be really helpful if the generated Kotlin bindings for the C had Kotlin source code, so that I could view the code and make more sense of it. At the moment in IntelliJ I can only view the decompiled bindings, which aren't very helpful (see screenshot).

Something else that would be great is if the generated Kotlin bindings had comments/docs from the original code. Or a link to the source C code, so that I can at least quickly navigate to the code. This would help to see how the original functions are supposed to be used, and that would help me use them in Kotlin.

These are nice extras, and can be added to a 'nice to have' list.

[Oleg Yukhnevich]

C++ is on my list of possibilities, but I haven’t yet investigated it. Libclang allows to parse C++, but I have no idea now what runtime API should be there. But definitely will be explored later!

[Oleg Yukhnevich]

Regarding generated code - now I do just generate Kotlin code, and not IR directly as cinterop does
There will be even documentation from C declarations - libclang supports this