I am just trying to convert my core KMP library to Kotlin 2.0.0 but this is prevented by a nasty bug...

# multiplatform

[Michael Paus]

I am just trying to convert my core KMP library to Kotlin 2.0.0 but this is prevented by a nasty bug in the compiler. In my code I have several occurrences of a code structure like this:

In commonMain:

interface MyService {
    fun myServiceMethod(): String
}

expect class MyServiceImpl: MyService

For all targets:

actual class MyServiceImpl : MyService {
    override fun myServiceMethod(): String {
        TODO("Not yet implemented")
    }
}

This compiles without problems with Kotlin 1.9.23 but results in the following error message when I switch to 2.0.0.

> Task :library:compileCommonMainKotlinMetadata FAILED
e: file:[...]/MyServiceImpl.kt:5:8 Class 'MyServiceImpl' is not abstract and does not implement abstract member 'myServiceMethod'.

Has anybody noticed similar problems or knows about an already existing bug report?

[Andrew Reed]

Could it be to do with what targets you are using/change of the targets dsl? Are you using the old style?

[streetsofboston]

In the commonMain, try to expect the myServiceMethod as well.

[Michael Paus]

In order to create a reproducer for this problem I have created a little test project derived from this template: https://github.com/Kotlin/multiplatform-library-template
Maybe that answers your question @Andrew Reed
@streetsofboston I don’t understand how you mean that.

myTestLib.zip

[Michael Paus]

Just as a side note: IntelliJ does not show any error in this code. The message only pops up if you actually build the project.

[streetsofboston]

I thought something like this in the commonMain may fix it, adding the expect for myServiceMethod

expect class MyServiceImpl: MyService {
    expect override fun myServiceMethod(): String
}

but this 'work-around' doesn't work, at all... 🙂

[Michael Paus]

I already found a work-arround myself by introducing an intermediate abstract class but this makes the whole code very ugly.

[Dmitry Stakhov]

@streetsofboston @Michael Paus

expect class MyServiceImpl: MyService {
      override fun myServiceMethod(): String
 }

actual class MyServiceImpl : MyService {
     actual override fun myServiceMethod(): String {
         TODO("Not yet implemented")
     }
 }

[Michael Paus]

@Dmitry Stakhov You are right. That works but it is a lot of code duplication. I still wonder whether this is an intended breaking change or a bug.

[Vladimir Vainer]

I have the same problem, and what worse, is it behaves kinda randomly.
Sometimes it compiles, sometimes other errors in code trigger this error. And then it's hard to get rid off.
In the end, i just use an interface, without expect at all. And just inject the proper implementation.
But It's eating at me that I can't find a proper documentation for this issue.

[Alex]

You might just want to get rid of the expect class and use an expect interface with platform specific implementations and expect fun extensions, jetbrains people said expect class is tricky and will have bugs

[Alex]

See this comment from Roman Elizarov: https://youtrack.jetbrains.com/issue/KT-61573/Emit-the-compilation-warning-on-expect-act[…]rning-must-mention-that-expect-actual-classes-are-in-Beta