NoSuchMethodError when using @ExperimentalTime methods in arrow-fx-coroutines with Kotlin 1.5

[kageru]

Kotlin 1.5 changed the implementation of kotlin.time.Duration from inline class(val value: Double) to value class(val value: Long). The current release of Arrow depends on the Kotlin 1.4 standard library, so methods like arrow.fx.coroutines.Schedule.spaced(Duration) generate bytecode for spaced-LRDsOJo(double) (the random characters are expected name mangling to avoid conflicts when using inline classes as parameters).
When compiling a project with Kotlin 1.5, this results in a NoSuchMethodError at runtime.

Small example:

package arrowtest

import arrow.fx.coroutines.Schedule
import kotlin.time.Duration
import kotlin.time.ExperimentalTime

@ExperimentalTime
suspend fun main() {
  Schedule.spaced<Any>(Duration.seconds(1)).repeat { println("Hello Arrow") }
}

results in

> Task :app:run FAILED
Exception in thread "main" java.lang.NoSuchMethodError: 'arrow.fx.coroutines.Schedule arrow.fx.coroutines.Schedule$Companion.spaced-LRDsOJo(long)'
        at arrowtest.AppKt.main(App.kt:9)
        at arrowtest.AppKt$main$3.invoke(App.kt)
        at arrowtest.AppKt$main$3.invoke(App.kt)
        at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$1.invokeSuspend(IntrinsicsJvm.kt:205)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlin.coroutines.ContinuationKt.startCoroutine(Continuation.kt:115)
        at kotlin.coroutines.jvm.internal.RunSuspendKt.runSuspend(RunSuspend.kt:19)
        at arrowtest.AppKt.main(App.kt)

FAILURE: Build failed with an exception.

Kotest recently switched to including the stdlib as compileOnly in gradle to prevent issues like this one. Given that inline classes are erased at compile time, I don’t know if that would have helped here, but it might be worth looking into.

[rachelcarmena]

Hi @kageru , thanks!

Kotest recently switched to including the stdlib as compileOnly in gradle to prevent issues like this one. Given that inline classes are erased at compile time, I don’t know if that would have helped here, but it might be worth looking into.

Yes, it was done in Arrow as well from 0.12.x and 0.13.x (included): #2320

For instance, to check it:

• https://repo1.maven.org/maven2/io/arrow-kt/arrow-fx-coroutines/0.11.0/arrow-fx-coroutines-0.11.0.pom includes stdlib
• https://repo1.maven.org/maven2/io/arrow-kt/arrow-fx-coroutines/0.13.2/arrow-fx-coroutines-0.13.2.pom doesnt' include stdlib

So could stdlib come from a transitive dependency?

[rachelcarmena]

I updated the link of the related change: #2320

[kageru]

My test project is built with Kotlin 1.5, so it depends on the 1.5 stdlib.
I guess that means a compileOnly stdlib in Arrow won’t help for breaking API changes like this one, so my only options are to either not use the Duration overloads of the functions in Arrow or to keep using Kotlin 1.4 until Arrow updates to 1.5.

And speaking of which, are there plans for this or do you want to stay on 1.4 for a while?

[rachelcarmena]

Oh, ok, thanks @kageru. All the things are moving to Kotlin 1.5 now. However I'd recommend you the first option right now (not using spaced with Duration but Double). Thanks!

[kageru]

Okay, I’ll try to do that (not sure yet how often we use those functions in our projects; I only stumbled upon one so far, so it’s probably not too much effort to change).
Do you want to leave this issue open until you’ve finished moving to Kotlin 1.5?

[rachelcarmena]

Yes, please, thank you so much @kageru !

[raulraja]

Hi @kageru, We are now in 1.5.10 in main in Arrow, closing this but feel free to reopen if the next release gives you any issues