[BUG][KOTLIN] Generator 7.16.0 for Kotlin uses experimental `kotlin.time.Instant` without marking it

[LarsSven]

Description

OpenAPI generator v7.16 suddenly starts generating kotlin.time.Instant properties within data classes, however this is an experimental class that must be annotated with '@kotlin.time.ExperimentalTime'. Since it is not annotated with that annotation, compilation of the generated source code fails

openapi-generator version

7.16.0

Reproducer

1. git clone https://gitlab.com/rug-digitallab/resources/docker-kotlin.git
2. git checkout renovate/openapigeneratorversion
3. Observe failure when running ./gradlew assemble

[wing328]

I think it's related to #21866

@WonderCsabo can you please take a look when you've time?

[LarsSven]

Maybe as a bit of info, instant is experimental in 2.2.20, and stable in 2.3

[wing328]

thanks for the info

for 2.2.x, what do you guys use instead of kotlin.time.Instant ?

kotlin 2.3 is still in beta so we may need to come up with an option to fallback to something else other than kotlin.time.Instant ?

[WonderCsabo]

Previously the type was kotlinx.datetime.Instant which is already deprecated. We have to use kotlin.time.Instant from now on.

In the generator, we already opt-in in the build.gradle file, so the code can compile fine. However, this file is not used when generating code via the OpenAPI generator Gradle plugin. We can move the opt-in to the generated Kotlin files, to cover that scenario as well.

[LarsSven]

Yeah kotlin is in a weird scenario where 1 is deprecated and 1 is experimental. So far we've stuck to the deprecated one but we'll migrate soon

[CHervaudBetclic]

The kotlin client have a dateLibrary option, where we can specify which date library to use (e.g. kotlinx-datetime)
Instead of replacing the default one like it has been done, we should have introduce a new value for this option (probably something like kotlin) to use the new experimental type and not introduce a silent breaking change for openapi generator users with dateLibrary set to kotlinx-datetime

[WonderCsabo]

kotlinx-datetime option still uses the classes from the Kotlinx datetime library. They only moved Instant to the Kotlin standard library, bot the other date types are still in kotlinx. Therefore creating a new option is not justified, because really the current kotlinx-datetime option changed. Maybe we should have added this change in a major 8.x release. On the other hand that we would have result in generating code with deprecated types for people who already update Kotlin. I agree with @LarsSven that Kotlin put us in a weird situation with this change.

[LarsSven]

We will soon globally opt into the new experimental API, but it's of course not something many people will have opted into.

[CHervaudBetclic]

My major issue here is that we've broke existing configuration that used to work well, without any breaking change mention. Indeed a breaking change could have been justified, but even a small text saying next to the update Kotlin and libraries versions text in the release notes could have indicate that upgrading to 7.16 with kotlinx.datetime <7.0.0 would break.

IMO we should add a kotlinx-datetime-pre7.0.0 (or something like that) to let people use the new versions of the openapi generator (for global changes like new openapi specs versions support or anything) with the "old" kotlinx-datetime version until the kotlinx-datetime have fully been migrated to the kotlin standard.

[WonderCsabo]

By the way as a workaround, you can add custom type mappings to use the previous Instant type:

typeMappings.putAll(
        mapOf(
            "date-time" to "Instant",
            "DateTime" to "Instant"
        )
)
importMappings.putAll(
        mapOf(
            "Instant" to "kotlinx.datetime.Instant"
        )
)