Gradle ships with a specific Kotlin version, and Gradle version 8.8 is the newest gradle version that is verified compatible with kotlin 2.0.20. However, Gradle 8.8 itself in its buildscript and settings script runs Kotlin version 1.9.22 as can be seen by printing KotlinVersion.CURRENT in a build.gradle.kts script.

If a gradle plugin author tries to include serialization plugin 1.7.1, everything works fine. But upon upgrading to 1.7.2, we are immediately hit with a runtime error during a gradle build:

Caused by: java.lang.NoClassDefFoundError: kotlin/uuid/Uuid
	at kotlinx.serialization.internal.PrimitivesKt.<clinit>(Primitives.kt:20)
	at kotlinx.serialization.descriptors.SerialDescriptorsKt.PrimitiveSerialDescriptor(SerialDescriptors.kt:91)

This error is unavoidable, as the serialization plugin attempts to load the new kotlin UUID class regardless of whether or not the consumer is trying to serialize or deserialize a UUID.

To Reproduce

1. Write a gradle plugin which depends on serialization 1.7.2
2. Apply that gradle plugin in a project using Gradle 8.8
3. In the buildscript, settings script, or in the plugin itself, attempt to serialize or deserialize something
4. Observe error

Expected behavior

I think its ok for consumers of get a runtime error if they try to serialize or deserialize a kotlin.uuid.UUID in a gradle build. In that case, of course the UUID class will not be available. But for this whole library to fail seems unnecessary. Making the loading of the UUID class conditional on whether or not it is used would retain backwards compatibility in the library.