Contribution: KotlinX Serialization Support

[sgammon]

Hey there Pkl authors,

I was browsing the Pkl codebase and noticed there is no support just yet for KotlinX serialization in the code generator. The library is present, but isn't supported in the code generator yet or passed on as an API dependency.

One small wrinkle is that it looks like the currently declared version of KotlinX Serialization is incompatible with the project's version of Kotlin. To remedy this, there are a few options:

• Upgrade Kotlin to 1.8.x or later
  • There are probably already plans for this and it's a pretty big change, plus, with the dependencies in the embedded compiler / scripting layer, this would need deeper code changes
• Downgrade KotlinX Serialization to an earlier version, built with compatible metadata
  • Unclear how this would affect current use of the library
• Upgrade project's build-time Kotlin to 1.8.x or later, keep embedded Kotlin pinned
  • I've tried this locally and it worked for most modules right away; I'm diagnosing some test failures but they seem innocuous or unrelated

Other than this wrinkle, adding KotlinX Serialization might not be such a huge change. The code generator could add the @Serializable annotation to trigger code-gen; the runtime dependency could probably be omitted from the api or made optional, so long as docs listed instructions for users to install their own KotlinX dependency.

Would you guys be open to a PR to add such functionality?

[bioball]

Feel free to PR! This sounds like something that should be feature flagged.

For users that opt in, the kotlinx.serialization library itself should be a compile dependency of their projects; it doesn't need to be an api dependency in any of our libraries.

[sgammon]

Thank you @bioball! I've filed as #196. Currently in draft and should be cleaned up and ready soon.

[holzensp]

I think we can now start following versions more closely, with the drop of JDK 11 support for the upcoming 0.26. Extra serialisation support is certainly welcome.

[sgammon]

In my first approach in #196, I got it working, in the sense that Serializable can now be emitted in the generated Kotlin. It isn't quite there, yet, for a few reasons:

• Due to the relocations in fat JARs, the annotation must be emitted carefully (so it will not be subject to rewriting)
• The tree of classes, objects, and properties for a given snippet of Pkl is not necessarily Kserializable; for example:

Given the Pkl snippet:

open class Something {
  name: String? = null
}

class SomethingElse extends Something {
  // ...
}

@Serializable
open class Something(
  open val name: String
) : java.io.Serializable {
  // ...
}

// ...

@Serializable
class SomethingElse(
  name: String,
  val version: String,
) : Something(name), java.io.Serializable {
  // ...
}

The above yields:

This class is not serializable automatically because it has primary constructor parameters that are not properties

Moving the property to an override doesn't work either:

Serializable class has duplicate serial name of property 'name', either in the class itself or its supertypes

I think, then, that in this example, Sample would have to be a sealed interface:

@Serializable
sealed interface Something {
  val name: String
  fun copy(name: String): Toolchain
}

@Serializable
data class SomethingElse(
  override val name: String
): Something {
  override fun copy() = /* ... */
}

I'll keep playing with it and see if I can nail down the minimal suite of changes to support this. There are a few things we could do:

• Code-generate and provide Serializer implementations. This would maybe get around this limitation, but adds a lot of complexity to the code generator, and certainly some footprint.

• Change the generated Kotlin structure to be Kserializable from zero. Unclear what changes this would require just yet, I'll need to see what else breaks.