Compatibility guide for Kotlin Multiplatform
This guide summarizes incompatible changes you might encounter while developing projects with Kotlin Multiplatform.
Auto-generated targets
What's changed?
Target accessors auto-generated by Gradle are no longer available inside the kotlin.targets block. Use the findByName("targetName") method instead.
Note that such accessors are still available in the kotlin.targets case, for example, kotlin.targets.linuxX64.
What's the best practice now?
Before | Now |
|---|---|
kotlin {
targets {
configure(['windows',
'linux']) {
}
}
}
| kotlin {
targets {
configure([findByName('windows'),
findByName('linux')]) {
}
}
}
|
When do the changes take effect?
In Kotlin 1.7.20, an error is introduced when using targets accessors in the kotlin.targets block.
For more information, see the corresponding issue in YouTrack.
Gradle input and output compile tasks
What's changed?
Kotlin compile tasks no longer inherit the Gradle AbstractCompile task that has the sourceCompatibility and targetCompatibility inputs, making them unavailable in Kotlin users' scripts.
Other breaking changes in compile tasks:
What's the best practice now?
Before | Now |
|---|---|
The | Use the |
The | Compile tasks still implement the |
The | Use the |
The | All compile tasks now use the |
When do the changes take effect?
In Kotlin 1.7.20, inputs are not available, the output is replaced, and the classpath property is deprecated.
For more information, see the corresponding issue in YouTrack.
New configuration names for dependencies on the compilation
What's changed?
Compilation configurations created by the Kotlin Multiplatform Gradle Plugin received new names.
A target in the Kotlin Multiplatform project has two default compilations, main and test. Each of these compilations has its own default source set, for example, jvmMain and jvmTest. Previously the configuration names for the test compilation and its default source set were the same, which might lead to a name clash resulting in issues when a configuration marked with platform-specific attributes is included in another configuration.
Now compilation configurations have an extra Compilation postfix, while projects and plugins that use old hard-coded configuration names no longer compile.
Configuration names for dependencies on the corresponding source set stay the same.
What's the best practice now?
Before | Now | |
|---|---|---|
Dependencies of the | jvm<Scope>
| jvmCompilation<Scope>
|
dependencies {
add("jvmImplementation",
"foo.bar.baz:1.2.3")
}
| dependencies {
add("jvmCompilationImplementation",
"foo.bar.baz:1.2.3")
}
| |
Dependencies of the | jvmMain<Scope>
| |
Dependencies of the | jvmTest<Scope>
| jvmTestCompilation<Scope>
|
Dependencies of the | jvmTest<Scope>
| |
The available scopes are Api, Implementation, CompileOnly, and RuntimeOnly.
When do the changes take effect?
In Kotlin 1.8.0, an error is introduced when using old configuration names in hard-coded strings.
For more information, see the corresponding issue in YouTrack.