I try to convince Google bringing Brotli to Kotlin Multiplatform. They already support Kotlin on JVM...

# feed

[Stefan Oltmann]

I try to convince Google bringing Brotli to Kotlin Multiplatform. They already support Kotlin on JVM now, but that’s not enough for a KMP JPEG XL support.

Maybe you can add your 👍 to my comment on GitHub, too:
https://github.com/google/brotli/issues/1123#issuecomment-1959893441 🙂

[Stefan Oltmann]

@louiscad Your post has inspired me, highlighting the potential for our community to exert influence on crucial JVM-only/Android-only libraries, thereby demonstrating to developers the demand for Kotlin Multiplatform (KMP) support. 😊

One immediate example that comes to mind is the absence of a KMP solution for PDF creation. Perhaps we could select a reputable PDF library like Apache PDFBox and advocate for KMP compatibility there. 🤔

[ephemient]

Brotli depends on NIO, PDFBox depends on a ton of Java stuff including reflection

[ephemient]

there's not an easy path to making them multiplatform

[Stefan Oltmann]

Good point, maybe PDFBox is not a suitable ground for a KMP transformation.

[Stefan Oltmann]

For XMP Core I was lucky that @pdvrieze already took the demanding task making of bringing XML parsing to KMP. The other dependencies already had KMP replacements.

I didn't look into PDFBox dependencies, but reflection indeed doesn't sound good.
Reflection shouldn't be necessary for a lib like that, either. 🤔

[ephemient]

it's to handle different things available in different Java versions

[ephemient]

(such as IO)

[Stefan Oltmann]

Java NIO should be fully replaceable by kotlinx-io. Maybe even all of the IO needs.

[ephemient]

eventually, maybe. definitely not yet, and that introduces interop questions for existing Java users…

[Stefan Oltmann]

I try to wrap my head around that. 🤔

Why do we need interop for existing Java users?
If a KMP port has the same API and the same parameters lead to the same results, where is the problem?

[Stefan Oltmann]

I might miss something here. For translating Apache Commons Imaging to KMP I first wrote unit test to freeze input->output for a lot of sample files. After I was done (including replacing all IO with kotlinx-IO) I had a pure KMP port that had the very same results for the same inputs as the original JVM version, but on all platforms.

If the reflection stuff in PDFBox is to select appropriate API on older JVM versions I would just drop all of that, because Kotlin produces Java 8 bytecode compatible code. It would not support older JVMs then, but that would be fine in my view, because that's all legacy. No need to provide a solution for that in my view.

[louiscad]

There is okio for Multiplatform I/O.

[ephemient]

NIO is not only an internal usage but also part of the exposed API I believe

[Stefan Oltmann]

AFAIK kotlinx-io is a okio fork.

[ephemient]

kotlinx-io is rebasing on a fork of but going to be a different API than okio as far as I know

[ephemient]

anyhow imo it's certainly possible to fork those libraries to convert to Kotlin multiplatform, but I'm not sure they'd do so upstream…

[Stefan Oltmann]

I still don't really understand what you mean with "interop questions for existing Java users"

[ephemient]

because they can call into brotli with NIO buffers

[Stefan Oltmann]

fork those libraries

I forked Commons Imaging, because the original project is dead. So there is no upstream.

For alive libraries that still may change (like Brotli; don't know about PDFBox) a first class support is better.

[Stefan Oltmann]

because they can call into brotli with NIO buffers

Ah, now I got you. You mean that the methods taking Java NIO buffers as arguments of the official API would change to the kotlinx-io equivalent.

[Stefan Oltmann]

Yes, indeed. Support for JVM- or Android-only classes as parameters or return types may be lost during a KMP transformation. That's an interopability concern, right.

[Stefan Oltmann]

For Kim I added them back like here, but how to proceed with a NIO ByteBuffer in a Brotli KMP is a good question, that may be only answered upon taking a closer look.

https://github.com/Ashampoo/kim/blob/80028c814de583737f3a95599745d12ca5051df8/src/jvmMain/kotlin/com/ashampoo/kim/JvmKimExtensions.kt#L25-L26

[Stefan Oltmann]

If I find the time I think I will take the challenge to make a Brotli KMP fork and see where the problems are.

But first I want to see if Google / eustas are willing to provide first party KMP support.

Keeping up to date with a living project may be some work.