What is the best way to embed native libraries with Kotlin/JVM libraries? I don't like having the na...

# compose-desktop

[mohamed rejeb]

What is the best way to embed native libraries with Kotlin/JVM libraries? I don't like having the native libraries in resources.
There's a part in Compose Desktop docs talking about but it's only for the final executable and not mentioning libraries.
I'm not sure how skiko does it.

[Michael Paus]

There recently was a discussion about how to deal with native libraries on the application level. See: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1707138858017139

But I have to admit that I also don’t know how to deal with that on the library level. The problem is not so much getting that to work from the IDE because many libraries already do that. The problem is to later get the packaging right so that the resulting application also conforms to the various requirements of the stores and other sandboxed environments.

[mohamed rejeb]

For the app level, I'm using conveyor and it handles native libraries perfectly. You can put all native libraries in resources and conveyor will know which libraries is needed for each os and put it in the right place.

[Michael Paus]

Does conveyor automatically extract all native libraries from JAR files and places them in resources or do I have to do that myself?

[mohamed rejeb]

Yes it does it automatically for libraries from JAR files. I'm talking about adding custom native libraries, I can put them in resources and conveyor moves them from resources dir Contents/Resources to libs dir which is for macOS for example Contents/runtime/Contents/Home/lib

[mikehearn]

Yes unfortunately there is no standard for this in the JVM ecosystem. Conveyor does a lot of work to cover this fact up, but even then it's not 100% transparent. There is a need for someone to show leadership and make native code packaging with Maven/Gradle work a lot better.

[mikehearn]

For small libraries, it's easiest to just bundle into the main JAR for your library. For large libraries, it's best to break it out into other JARs. You can then either write a build system plugin to pick the right one, or require the consumer to add a dependency on the machine-specific JAR.

[Michael Paus]

@mikehearn Bundling is one part but it’s also important how you try to load the library from your code. If you unpack the native library at runtime you may end up with the same problem as described in my first reply above with sqlite.

[mikehearn]

Yes. At some point I wanted to write a generic loader library that handles all this unpacking nonsense, but I never got around to it.

[mikehearn]

With the arrival of Panama it's possible that native code will become more prevalent in the JVM ecosystem so someone should try to solve this.