Can't update dependency kotlinxSerialization to 1.7.2

[bingningO]

hello we're trying to update org.jetbrains.kotlinx:kotlinx-serialization-json from 1.7.1 to 1.7.2, but

got error like:

* What went wrong:
Execution failed for task ':ui:app-review:app-review-common:finalizeTestRoborazziDebug'.
> Could not initialize class com.github.takahirom.roborazzi.CaptureResults

---

p.s.
according to the changelog , seems is this change caused it :

[takahirom]

Thanks. I'll look into this.

[takahirom]

@bingningO Could you share the stacktrace as I'm not sure what problem you saw?🙇

[takahirom]

I couldn't reproduce the issue. There may be a condition that causes this issue to occur. 👀
DroidKaigi/conference-app-2024#1037

[ZacSweers]

1.7.2 was a broken release, use 1.7.3: https://github.com/Kotlin/kotlinx.serialization/releases/tag/v1.7.3

[ZacSweers]

We do see a possibly slightly related issue

Could not initialize class com.github.takahirom.roborazzi.CaptureResults
> Exception java.lang.NoClassDefFoundError: kotlin/uuid/Uuid [in thread "Execution worker Thread 4"]
....
....
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NoClassDefFoundError: kotlin/uuid/Uuid [in thread "Execution worker Thread 4"]	

[ZacSweers]

I think the problem is that roborazzi is attempting to use the new Uuid type in kotlin 2.0.20, but gradle forces kotlin 1.9 still

I see the gradle plugin depends on/uses roborazzi-core here: https://github.com/takahirom/roborazzi/blob/main/include-build/roborazzi-gradle-plugin/build.gradle#L17

[ZacSweers]

forcing to 1.7.3 appears to resolve the issue. Might help users if there was a patch release with the fixed transitive version

[takahirom]

Thank you. I still don't understand the problem.

• Versions 1.7.2 and 1.7.3 use kotlin/uuid/Uuid, which was introduced in Kotlin 2.0.20.
• Version 1.7.3 seems to ignore the error as mentioned in the release notes.
• The Gradle build can't use Kotlin 2.0.20.
• When is the generation of CaptureResults's Uuid? Is it when building the plugin or when building the library user's project?
  • I think it is the user's project because the error occurs and Roborazzi doesn't use Kotlin 2.0.20.

What I'm not sure about:

• Is this problem solved by updating KotlinX Serialization to 1.7.3 in the user's project?
  • Maybe not, because there are reports.
    • But why? Shouldn't version 1.7.3 ignore the error?

[takahirom]

Is the BuildScript dependency something like this?

• KotlinX serialization runtime 1.6.3, which doesn't catch the problem.
• KotlinX serialization plugin 1.7.3, which generates the Uuid.
• Kotlin 1.9, which doesn't have Uuid

Anyway, I would like to have a reproducible project.

[takahirom]

I was able to reproduce the issue by adding 1.7.2 buildscript dependency but I was able to fix it by updating it to 1.7.3.

buildscript {
    dependencies {
        classpath(libs.kotlinSerializationJson) // 1.7.2
    }
}

[takahirom]

Roborazzi can update kotlinx serialization to 1.7.3, but it forces users to update to Kotlin 2.x or higher.

[ZacSweers]

I don't think it imposes it any more than before tbf. The problem before was something in clinit in kotlinx-serialization that just happened to burn roborazzi since it uses it

[takahirom]

I would like to know if there are patterns where users can't fix the problem even after updating Kotlinx Serialization to version 1.7.3. If it is just a 1.7.2 problem, I don't think the severity of the issue is that high.

[trevjonez]

Was able to just bump our consuming project up to 1.7.3 and the issue went away. Might not always be a fix that is available for everyone depending on the overall classpath layout of the build though?

edit: may have spoke too soon. still seeing it in a few sub projects.

[takahirom]

@trevjonez
Thanks. Does that happen even if you use version 1.7.3? Could you provide the output of ./gradlew buildEnvironment related to Kotlinx.Serialization?

[takahirom]

Even if we update Kotlinx.Serialization to version 1.7.3 in the Roborazzi Gradle Plugin, the Kotlin runtime version might not change. I believe this is why the issue has occurred: the Kotlin runtime was not updated when we upgraded Kotlinx.Serialization to version 1.7.2 or 1.7.3, and the Kotlin runtime doesn't include the Uuid class. Therefore, we could update the Gradle Plugin to use Kotlinx.Serialization 1.7.3. However, for the roborazzi module, it is not advisable to update Kotlinx.Serialization to 1.7.3 because it affects the users' Kotlin runtime version.
We could add Kotlinx.Serialization version 1.7.3 in the Roborazzi Gradle Plugin.

[takahirom]

The basic policy is not to update to the latest version of libraries in Roborazzi, so as not to force users to update. Therefore, if it is not necessary, it would be preferable not to do so. I would like to check if version 1.7.3 works or not.

[trevjonez]

Ok so after digging in more I found another plugin that was leaking kotlin stdlib 2.+ thru its dependencies into the build dependencies classpaths. Oddly it would auto resolve the 2.0.10 down to a 1.9 version in some cases hiding the issue longer than I would have expected. None of that had to do directly with kotlinx serialization directly though so I suspect there is some sort of dynamics at play at runtime that trigger the behavior change to break in the razzi tasks. Once I got the build classpath sorted such that all of the plugins and libraries top out in the kotlin 1.9 range everything is fine.

I still have some plugins that depend on things like okio pulling in with them stdlib 2.+ but it doesn't seem to bother razzi I assume from those tasks not being used in the same invocation as when we run the tests.

[bingningO]

forcing to 1.7.3 appears to resolve the issue

sorry for late response...

I tried this it worked 🙇🏼