Bundle Kotlinx Serialization into library
ejektaflex opened this issue ยท 2 comments
I'd like to see Kotlinx Serialization bundled into Fabric Language Kotlin. I've preferred to use that over Gson for a lot of things, and it works better for Kotlin as it currently stands.
The 0.4.X loader page on nested Jars says this library should probably be bundled into a mod, since it probably couldn't be repackaged and multiple mods would use it.
As such, this way we don't have to rely on multiple third party mods (which may have wider scopes than just including the library, and are not up to date).
This would include both the Serialization library as well as it's JSON library.
A bit more detail after figuring things out for a day:
The current version of Kotlinx Serialization to include would be:
kotlinx-serialization-core
and kotlinx-serialization-json
, both version 1.0.1
, both of which can be found on jcenter()
, if I recall correctly.
It seems that if you include KotlinX Serialization from another mod (such as from FabricDrawer), then when you run your mod in IntelliJ it all works fine. However, if you include it in your own mod via modApi
and include
in the exact same way, then suddenly you get this:
Caused by: java.lang.LinkageError: loader constraint violation: loader 'app' wants to load interface kotlin.reflect.KType.
A different interface with the same name was previously loaded by net.fabricmc.loader.launch.knot.KnotClassLoader @64a40280.
(kotlin.reflect.KType is in unnamed module of loader net.fabricmc.loader.launch.knot.KnotClassLoader @64a40280,
parent loader net.fabricmc.loader.launch.knot.KnotClassLoader$DynamicURLClassLoader @3d3e5463)
This happens from running the following code:
val str = Json.encodeToString<Int>(1)
This internally calls typeOf<Int>()
which classloads KType
, causing the above issue. However, if we were to load KSX from FLK, then this would no longer be an issue.
This issue seems to have popped up several times over the last year (just search the Discord for java.lang.LinkageError
!), and the issue never gets resolved. Including KSX into the official FLK adapter would fix a lot of headaches for people!
It seems that this bug is caused by Fabric Language Kotlin and Loom - when FLK is included as a modImplementation
, KSX throws the above error. This seems to be because kotlin-stdlib
and kotlin-reflect
are loaded as mods, but not stripped/extracted when Loom runs. This causes duplicates of Reflect in the classpath, which caused the above error.
Regardless of the cause, it would still be excellent if we included KSX-core and KSX-json in FLK.