Kotlin Multiplatform Support

[michaelcosta]

Just wondering if there's any plans to support Kotlin Multiplatform once the Kotlin export is officially supported as well? Currently it's using the jvm runtime jar that isn't setup as a multiplatform library, which I believe would require a decent amount of work to migrate.

[dbaileychess]

@paulovap

[paulovap]

I am working on it, but it has been fairly slow to be honest.

Most of it is done, just need a few more tests and integration with Java's ByteBuffer for compatibility. You can follow the progress here

https://github.com/paulovap/flatbuffers/tree/pp/kotlin_fb_runtime

I cannot give a ETA, given my limited time unfortunately. But would accept external help.

[michaelcosta]

Most of it is done, just need a few more tests and integration with Java's ByteBuffer for compatibility. You can follow the progress here

Would you be able to provide a quick rundown on what that would entail? I might be able to help out as it could save us a lot of dev effort overall by simplifying our mobile parsing. I see you've got the ArrayReadWriteBuffer backed by just ByteArray, where would the ByteBuffer integration need to happen?

[michaelcosta]

@paulovap ping in case I can be of assistance

[paulovap]

@paulovap ping in case I can be of assistance

I @michaelcosta. I tried to breakdown the changes to see if I can get more external support, but the way it is right now it's not possible. I will need more time to shape the change better so it can be parallelized. I will ping you once I have something I can work with.

[mikeholler]

Hi @paulovap, I'm also interested in exploring an external support option to see if it would work with our team. We are currently attempting to build a common layer around the artifacts from the java, javascript, and flatcc generated sources, and there are a lot of implementation quirks between them that are hard to reconcile.

[ptitjes]

@paulovap I am interested in continuing/finishing the work you started in https://github.com/paulovap/flatbuffers/tree/pp/kotlin_fb_runtime.

Can we discuss this? Can I start from this branch or do you have something newer?

[paulovap]

@paulovap I am interested in continuing/finishing the work you started in https://github.com/paulovap/flatbuffers/tree/pp/kotlin_fb_runtime.

Can we discuss this? Can I start from this branch or do you have something newer?

Hi @ptitjes @mikeholler sorry for the delay. Summer vacations. I will try to clean up the branch and write down what needs to be finished in the next couple of weeks.

[mikeholler]

Hi @paulovap, how are things going? Any progress on your comment from August?

[ptitjes]

Hi @paulovap ! Do you think we can go forward with you #7812 pull request?
We could build upon it further later for the support of Okio and Java's ByteBuffer, right?

Do you need some help?

[paulovap]

I have re-open the pull request #7969.

I am still unhappy with few things on this PR:

• The API is now making use Offset instead of Int for reference to tables and indirections. But value class in Kotlin is full of holes and moving parts, easily falling into boxing, so the API looks a bit weird with some typealiases.
• Performance is just ok, but not on part with Java counterpart.
• Missing adding imports only when needed
• Avoid fully qualified names when there is no need (e.g. classes from same package).

But I have been dragging this for too long, so maybe it is better to push and already and have the community to help improve it.

So please @ptitjes @michaelcosta @mikeholler take a look at the new API, give some feedback, advice etc. Keep in mind that performance has priority over ergonomics.

[JJSarrasin]

Hi Paulo,

Can we expect to find it soon in a release or pre-release to allow a maximum people to test it easily by changing the gradle import line ?

[ptitjes]

Hi @paulovap! Sorry for the very late reply.

I finally found time to test the latest flatbuffers-kotlin. It seems to work fine for my use-case.

I am trying to make an adapter for the new kotlinx-io buffers to the ReadBuffer and ReadWriteBuffer interfaces and I have some initial concerns w.r.t. these APIs:

0. Should we directly use the kotlinx-io API, now or when it is sufficiently complete for all the Flatbuffers/Flexbuffers use cases?

1. Shouldn't ReadBuffer and ReadWriteBuffer use Long indexes? The specific ArrayReadWriteBuffer would then (after adequate bounds check) convert those indexes to Int to read from the ByteArray.

2. There is a public inline val <T> T.value: T get() = this function at the end of the Flatbuffers.kt file. I can't see any use of this function and I believe it spams the namespace as it is very generic. Is it used for something I don't see?

3. I am worried by exposing the ReadBuffer.data() method which both allows unsafe access to the underlying memory and also presupposes that the underlying memory is a ByteArray. Shouldn't we rather expose some unsafe cursor functionality?

EDIT:

4. Also, why is ReadWriteBuffer extending ReadBuffer necessary? Couldn't we only have a WriteBuffer?

Please forgive me if any of these questions are dumb.