flatbuffers icon indicating copy to clipboard operation
flatbuffers copied to clipboard

Published 20 hours ago • verified publisher icon google

Kotlin Multiplatform Support

Open michaelcosta opened this issue 3 years ago • 13 comments

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.

michaelcosta avatar Mar 23 '22 15:03 michaelcosta

@paulovap

dbaileychess avatar Mar 31 '22 22:03 dbaileychess

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.

paulovap avatar Apr 01 '22 10:04 paulovap

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 avatar Apr 01 '22 21:04 michaelcosta

@paulovap ping in case I can be of assistance

michaelcosta avatar Apr 19 '22 15:04 michaelcosta

@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.

paulovap avatar Apr 20 '22 18:04 paulovap

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.

mikeholler avatar May 18 '22 16:05 mikeholler

@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?

ptitjes avatar Jul 28 '22 10:07 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?

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.

paulovap avatar Aug 19 '22 07:08 paulovap

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

mikeholler avatar Feb 02 '23 15:02 mikeholler

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?

ptitjes avatar May 17 '23 14:05 ptitjes

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.

paulovap avatar May 20 '23 09:05 paulovap

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 ?

JJSarrasin avatar Jun 14 '23 15:06 JJSarrasin

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:

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

  2. 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.

  3. 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?

  4. 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:

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

Please forgive me if any of these questions are dumb.

ptitjes avatar Sep 11 '23 12:09 ptitjes