Kotlin Multiplatform

[aSemy]

Hi, would it be possible to convert Kalasim to support Kotlin Multiplatform?

I'm experimenting with a Kotlin/Native based game library, and I'm curious about using Kalasim with it (instead of the JVM-only OPENRNDR).

I'd be more than willing to help out with this and create the PRs.

As part of this it would really help to tidy up the Gradle build logic into convention-plugins, to reduce some of the duplication. Again, I could go ahead and make the PRs: the only question is whether you'd like them to be incremental (break the PRs down into smaller steps, which might be more understandable but could stretch the work out), or big-bang migrate everything (which is my preference!).

[holgerbrandl]

Thanks for the great suggestion.

I had already thought about it, and to proceed here, we would first need to resolve JVM dependencies. Some dependencies (namely kravis and krangl) could be moved easily into a jvm-module as they do not contribute to the core of the library. What's harder to resolve are

1. PriorityQueue (for which there is no kotlin countpart afaik). This relates to https://github.com/holgerbrandl/kalasim/issues/48 because using some half-baked replacement is likely to impact performance significantly.
2. commons-math3:3.6.1 - Distributions support is crucial imho, so this would need to be migrated to something such a kmath or similar. Certainly doable but quite some work I think.

Once JVM dependencies have been removed, I'd be all in and ears to migrate the build system. I have no prior experience with multiplatform yet.

We could explore the refactoring in a separate branch I think, to allow me to evolve the core library independently until such a fix is complete.

[aSemy]

Thanks @holgerbrandl!

Instead of trying to remove JVM dependencies before proceeding, I think the first step could be to migrate the project to a multiplatform project that only targets JVM. Once that's done it becomes easier to try and resolve JVM specific issues, either with...

• alternative libraries (simpler, but adds additional dependencies),
• or by wrapping the JVM specific code with specific expect/actual code (might lead to different behaviour on platforms, so it would require specific testing),
• or porting code to a Kotlin-common implementation (more reliable behaviour, but more code to maintain).

Anyway, say the word and, if you'd like, I can start updating the Gradle config? 👍

[aSemy]

I've done some digging and these are the libraries that are not multiplatform compatible.

• org.apache.commons.math3.distribution (as you already noted)
• com.github.holgerbrandl.jsonbuilder (replace with Kotlinx Serialization?)
• org.jetbrains.kotlinx.dataframe (seems to be JVM/JS only)
• Java utils + associated functions (e.g. PriorityQueue, Map.merge(), Map.putIfAbsent(), ThreadLocal, java.awt.geom.Point2D, java.util.logging.Level, Thread.sleep(), UUID)
• There's some reflection based stuff using javaClass

There are also some JVM specific stuff which can be happily moved to jvmMain (or a specific subproject?), like the Jupyter notebook integrations.

There's also a notable amount of JUnit code, but that should be quite easily migratable to kotlin.test or Kotest.

[holgerbrandl]

Great analysis. I was not aware of quite some JVM dependencies. To me this also indicates that before revising the build structure, dependencies should be converted one-by-one (starting with the most complex ones) which I guess is non-trivial in some cases (e.g. reflection does not work on multiplatform afaik).

I'd think ordered by amount of work for to port this to KMP the list is

1. Reflection (unclear to me if this is possible at all)
2. PriorityQueue
3. Multithreading support (which is a crucial feature)
4. java utils (which is a lot of work)
5. json processing
6. commons-math
7. dataframe could be moved into jvm part, but this severly reduce the usefulness of the library imho

Given the number of JVM dependencies, it is actually imho quite possible that it's not feasible with the few resources available to convert the library into multiplatform, and if so I don't want to end up with a more complex revised build structure that would in such case serve no function, and would need to be rolled back eventually.

JVM bits could be separated in a special package/namespace until everything else is ready to go KMP.