I recently updated datetime time from 0.6 to 0.7 But then it crashing at runtime in 3rd party libs t...

# kotlinx-datetime

[Tomáš Procházka]

I recently updated datetime time from 0.6 to 0.7
But then it crashing at runtime in 3rd party libs that was build using older version on: "Failed resolution of: Lkotlinx/datetime/Instant"
It means that there is no way how to migrate to that new version until all libraries will migrate?
But nobody will migrate because nobody want to break somebody else project.
I was expected that Kotlin is able to follow that alias even in runtime and use right class instead of kotlinx/datetime/Instant.

[jw]

Use the compat version

[jw]

https://github.com/Kotlin/kotlinx-datetime?tab=readme-ov-file#deprecation-of-instant

[Tomáš Procházka]

Thanks!

[jw]

Don't forget to file a bug on the library, too!

[Tomáš Procházka]

It is our internal company library. It is even worse then with public one 😭.

[Tomáš Procházka]

I hope that maven/gradle will consider 0.7.1-0.6.x-compat as newer version than 0.7.1

[jw]

It does, intentionally so

[Tomáš Procházka]

But If some library will update in the future to 0.7.2 and other library will still use 0.6.X.
I will need to always update to the latest compat version in the application.

[jw]

For the 0.7.x series, you will always have to use -compat if you have dependencies built against 0.6.x and using the offending types.

[jw]

I believe the plan is for 0.8.x to not have a compat artifact, so work on fixing your dependencies.

[ephemient]

I was expected that Kotlin is able to follow that alias even in runtime

typealiases are resolved at build time and the result is baked into the compiled code (which is pretty much the only way to be JVM compatible)

[Tomáš Procházka]

It could create something like proxy class that will just call the original 😉

[jw]

The type could be final

[ephemient]

come to think of it, it should be possible to write a jetifier-style bytecode transform to fix libraries still using kotlinx.datetime.{Duration,Instant}. but if you have the source then fixing the library itself will still be easier