Kotlin: Support record & enum serialization #2753

paxbun · 2025-12-14T17:55:41Z

To-Dos:

Rename fixtures/swift-codable to fixtures/serialization?
More options to customize class discriminator for enum variants?
Any additional CI errors? What about Dockerfile-build.checksum?

paxbun · 2025-12-14T18:02:32Z

fixtures/swift-codable/tests/bindings/test_codable.kts

+assert(jsonRecordWithOptionals == """{"vec":["A","B"]}""")
+
+// ComplexEnum
+val withClassDiscriminator = Json { classDiscriminator = "#class" }


This will embed "#class": "ComplexEnum.String" into the resulting JSON string, but some may want to customize the value of that property as well. We can provide this via the @kotlinx.serialization.SerialName annotation, but I'm not sure there is an elegant way to customize it via the configuration file. I'm thinking of something like the custom type configuration, e.g.:

[bindings.kotlin.serialization.ComplexEnum.String] serial_name = "complex_enum_string"

which will put "#class": "complex_enum_string" to the resulting string.

Assuming you don't intend blocking this PR on that tweak, it might be worth opening a PR where we can discuss this, then add a short comment in the fixture itself which notes what you said and links to the PR, so people exploring this fixture also discovers this.

Re the idea for customizing, that seems good - another alternative might be a format similar to what we did for renaming - https://mozilla.github.io/uniffi-rs/next/renaming.html - which would be more like:

[bindings.kotlin.serialization.serial_names] "ComplexEnum.String" = "complex_enum_string"

(I've no idea if that example makes actual sense in this context, but some degree of consistency makes some sense)

paxbun · 2025-12-14T18:06:36Z

docs/contributing.md

-    added to your `$CLASSPATH` environment variable.
+  * Several JARs downloaded and their path added to your `$CLASSPATH` environment variable:
+    * [Java Native Access](https://github.com/java-native-access/jna#download)
+    * [KotlinX Serialization Core runtime](https://repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-serialization-core-jvm/1.6.3/kotlinx-serialization-core-jvm-1.6.3.jar)


The latest version of KotlinX Serialization is currently 1.9.0. Since the CI is also using KotlinX Coroutines 1.6.3, whose latest version is also 1.10.2, I chose a version released at the time, when Kotlin 2.0 had not been released yet.

Should we fix the Kotlin version and upgrade the dependencies here?

That makes sense to me. Also, here I think it might be worth mentioning that the serialization libs are optional - eg, something like "Optionally, if you choose to use the generate_serializable_types option so that serializable types are generated, you will need ..."?

paxbun · 2025-12-14T18:08:46Z

uniffi_bindgen/src/bindings/kotlin/gen_kotlin/mod.rs

    #[serde(default)]
    pub(super) rename: toml::Table,
+    #[serde(default)]
+    generate_serializable_types: bool,


Are there any better names for this?

maybe generate_serializable_annotation? That seems to better reflect what actually changes here (ie, it doesn't change how we render the type itself)?

paxbun · 2025-12-14T18:10:06Z

uniffi_bindgen/src/bindings/kotlin/gen_kotlin/mod.rs

        Ok(textwrap::indent(&wrapped, &" ".repeat(spaces)))
    }
+
+    fn serializable_type(ty: &Type, ci: &ComponentInterface) -> Result<bool, askama::Error> {


Would it be okay to make ComponentInterface::iter_types_in_item public and use it here?

yeah, that would be fine and better than copying it

mhammond

This is fantastic, thanks!

mhammond · 2025-12-15T04:27:33Z

docs/contributing.md

-    added to your `$CLASSPATH` environment variable.
+  * Several JARs downloaded and their path added to your `$CLASSPATH` environment variable:
+    * [Java Native Access](https://github.com/java-native-access/jna#download)
+    * [KotlinX Serialization Core runtime](https://repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-serialization-core-jvm/1.6.3/kotlinx-serialization-core-jvm-1.6.3.jar)


That makes sense to me. Also, here I think it might be worth mentioning that the serialization libs are optional - eg, something like "Optionally, if you choose to use the generate_serializable_types option so that serializable types are generated, you will need ..."?

mhammond · 2025-12-15T04:30:30Z

fixtures/swift-codable/tests/bindings/test_codable.kts

@@ -0,0 +1,62 @@
+/* This Source Code Form is subject to the terms of the Mozilla Public


I think it makes sense to rename this parent directory now? maybe something like "generated_serialization" or similar - this each test having a unique name would be ok (eg, "test_codable" for swift and "test_serialization" for kotlin.

I'm not too bothered if you don't want to do this here or would prefer it be done in a followup etc.

(The name "codable" always gets me - I don't immediately think "serialization" when I see it :)

mhammond · 2025-12-15T04:38:17Z

fixtures/swift-codable/tests/bindings/test_codable.kts

+assert(jsonRecordWithOptionals == """{"vec":["A","B"]}""")
+
+// ComplexEnum
+val withClassDiscriminator = Json { classDiscriminator = "#class" }


Assuming you don't intend blocking this PR on that tweak, it might be worth opening a PR where we can discuss this, then add a short comment in the fixture itself which notes what you said and links to the PR, so people exploring this fixture also discovers this.

Re the idea for customizing, that seems good - another alternative might be a format similar to what we did for renaming - https://mozilla.github.io/uniffi-rs/next/renaming.html - which would be more like:

[bindings.kotlin.serialization.serial_names] "ComplexEnum.String" = "complex_enum_string"

(I've no idea if that example makes actual sense in this context, but some degree of consistency makes some sense)

mhammond · 2025-12-15T04:42:15Z

uniffi_bindgen/src/bindings/kotlin/gen_kotlin/mod.rs

    #[serde(default)]
    pub(super) rename: toml::Table,
+    #[serde(default)]
+    generate_serializable_types: bool,


maybe generate_serializable_annotation? That seems to better reflect what actually changes here (ie, it doesn't change how we render the type itself)?

mhammond · 2025-12-15T04:46:03Z

uniffi_bindgen/src/bindings/kotlin/gen_kotlin/mod.rs

        Ok(textwrap::indent(&wrapped, &" ".repeat(spaces)))
    }
+
+    fn serializable_type(ty: &Type, ci: &ComponentInterface) -> Result<bool, askama::Error> {


yeah, that would be fine and better than copying it

paxbun added 4 commits December 15, 2025 01:07

Render @kotlinx.serialization.Serializable for serializable types

b06b7bd

Add URLs to KotlinX Serialization JARs to the contribution guide

b52a420

Pass the KotlinX serialization plugin to kotlinc

c487b93

Download KotlinX Serialization dependencies in CI

4077557

paxbun requested a review from a team as a code owner December 14, 2025 17:55

paxbun requested review from badboy and removed request for a team December 14, 2025 17:55

paxbun added the binding-kotlin label Dec 14, 2025

paxbun commented Dec 14, 2025

View reviewed changes

Add Kotlin unit tests to swift-codable fixture

855ae4e

paxbun force-pushed the feat/kotlin-serialization branch from 687cbb5 to 855ae4e Compare December 14, 2025 18:08

paxbun commented Dec 14, 2025

View reviewed changes

paxbun force-pushed the feat/kotlin-serialization branch 4 times, most recently from 004fa58 to 58a27b5 Compare December 15, 2025 03:15

mhammond reviewed Dec 15, 2025

View reviewed changes

paxbun force-pushed the feat/kotlin-serialization branch from 58a27b5 to cc28ea8 Compare December 15, 2025 04:55

Try search for the Kotlin compiler installation more thoroughly

c43dbde

paxbun force-pushed the feat/kotlin-serialization branch from cc28ea8 to c43dbde Compare December 15, 2025 05:46

		@@ -0,0 +1,62 @@
		/* This Source Code Form is subject to the terms of the Mozilla Public

Kotlin: Support record & enum serialization #2753

Are you sure you want to change the base?

Kotlin: Support record & enum serialization #2753

Uh oh!

Conversation

paxbun commented Dec 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhammond Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhammond left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhammond Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

paxbun commented Dec 14, 2025 •

edited

Loading

mhammond Dec 15, 2025 •

edited

Loading

mhammond Dec 15, 2025 •

edited

Loading