Kotlin 1.2.40 is here

On the road to Kotlin 1.2: Latest update adds new inspections and intentions to the Kotlin IntelliJ plugin

Gabriela Motroc

© Shutterstock / Michael.P

Kotlin 1.2.40, the newest bugfix and tooling update for Kotlin 1.2 brings a lot of goodies, including new inspections and intentions to the Kotlin IntelliJ plugin and improvements for the experimental multiplatform projects feature. Let’s take a look at what’s in this update.

There’s a new bugfix and tooling update for Kotlin 1.2 which adds new inspections and intentions to the Kotlin IntelliJ plugin, as well as @JvmDefault annotation which makes interface methods default in Java (experimental).

Furthermore, Kotlin 1.2.40 allows platform modules in experimental multiplatform projects to have more than one expectedBy dependency and enables support for crossinline suspend parameters in inline functions, according to the blog post announcing the update.

Let’s have a look at some of the highlights.

Improvements for multiplatform projects

Platform modules can now reuse the code and provide actual platform-specific implementations for declarations from more than one common module. You can add multiple expectedBy dependencies to the platform module, for example:

apply plugin: 'kotlin-platform-jvm'
// ...
dependencies {
    expectedBy project(":io-common")
    expectedBy project(":data-common")
    // ...

Since expectedBy dependencies are still non-transitive, if a common module, for example app-common, depends on another one, lib-common, then, in a platform module, you can either provide actual implementations for both, manually specifying the two as expectedBy dependencies, or add an expectedBy dependency on just app-common and a compile dependency on an existing platform module for lib-common.

The support for default parameters in expect functions and constructors has also been improved:

expect class StringMatcher {
    fun match(value: String, matchStrictly: Boolean = false): Boolean

However, keep in mind that you shouldn’t specify default parameter values for the actual counterparts since they are only allowed in expect declarations.

Crossinline suspend function parameters

Kotlin 1.2.40 enables support for inline function crossinline parameters of suspend function types, which can then be called inside nested suspending functions and lambdas:

inline fun schedule(crossinline runner: suspend () -> Unit)  {
    launch(CommonPool) {

Support declaring Java default interface methods

Kotlin 1.2.40 brings experimental support for generating default interface methods for the JVM target 1.8 and above. Although this feature is disabled by default, it can be enabled by passing a compiler flag -Xenable-jvm-default. Then an interface member with a body can be marked with the @JvmDefault annotation (from the kotlin.jvm package):

interface Foo {
    fun foo(): Int = 0

This functionality is experimental in Kotlin 1.2.x, so its design and implementation may change in future updates.

Visibility restrictions for types brought into scope through companion objects subtyping

Kotlin 1.2.40 introduces deprecation warnings and migration tools in the IDE plugin to make sure the migration is as smooth as it can be when it comes to potentially breaking changes in Kotlin 1.3 regarding classifiers visible through companion objects.

When a body of a type Foo uses a short (non-qualified) type name which is declared in a supertype of Foo‘s own companion object, or in the companion objects of Foo‘s supertypes, as well as in the supertypes of these companion objects, without a proper import statement, you’ll receive a warning with a quick-fix that adds the import.

In Kotlin 1.3, these short names will be invisible unless they are qualified or imported.

IntelliJ IDEA plugin improvements

There’s a new intention for adding and removing explicit labeled return for the result expressions in lambdas:

The list of improvements doesn’t stop here. Kotlin 1.2.40 brings new intentions for adding and removing annotation use-site targets, an inspection to highlight and remove unnecessary explicit companion object references, as well as a bunch of stability and performance improvements.

Here’s how to update the plugin: Tools → Kotlin → Configure Kotlin Plugin Updates and go to Check for updates now. You’ll also have to update the compiler and standard library version in your Maven and Gradle build scripts.


Update March 6, 2018

Kotlin 1.2.30 is here.

According to the blog post announcing the bugfix and tooling update, Kotlin 1.2.30 adds a new declaration in the standard library, which imitates the suspend modifier for lambda expression and there’s also support for TestNG inkotlin.test.

The new update brings support for Android modules in multiplatform projects and introduces a new feature in kapt for reporting annotation processing errors along with proper links to the original Kotlin declarations. Bugs in the compiler and IntelliJ plugin have been fixed and plenty of new inspections and intentions have been added to the IntelliJ plugin.

Kotlin 1.2.30 is compatible with all versions of IntelliJ IDEA from 2017.1 until 2017.3 and 2018.1 EAP, as well as with Android Studio 3.0.

Kotlin 1.2.30 highlights

Library changes

As we mentioned above, Kotlin 1.2.30 adds a new function to the Kotlin standard library with the following signature:

public inline fun <R> suspend(
    noinline block: suspend () -> R
): suspend () -> R = block

This function wraps a function literal into a value of a suspending function type and enables its usage as a suspending function.

Keep in mind that a suspend modifier for lambda expressions will be gradually introduced in the future Kotlin versions, and adding this function is the first step.

Thanks to Valeriy Zhirnov, another notable change is the support for the TestNG framework in kotlin.test. The new artifact kotlin-test-testng provides an implementation of Asserter on top of TestNG and maps the test annotations from kotlin-test-annotations-common to the TestNG test annotations.

Platform modules targeting Android

The update of the experimental multiplatform projects feature introduces support for Android platform modules. These modules should apply the corresponding plugin in the Gradle build script and can use the shared code from a common module:

apply plugin: ''
apply plugin: 'kotlin-platform-android'
// ...

dependencies {
    expectedBy project(":multiplatform-app")
    // ...

Kapt diagnostic locations

As of now, kapt, the Kotlin annotation processing tool, can offer links to locations in the original Kotlin code rather than generated Java stubs as it reports errors encountered during annotation processing. You can enable this feature by adding these lines to the Gradle build script (build.gradle):

kapt {
    mapDiagnosticLocations = true

IntelliJ IDEA plugin improvements

Kotlin 1.2.30 brings various improvements in the IntelliJ IDEA Kotlin plugin, including performance improvements, bug fixes, and new inspections and intentions. Furthermore, you can now paste Kotlin code into a package item in the Project View, creating a new Kotlin file for the code:

You can find the complete list of changes in the changelog.


Update January 17, 2018

Kotlin 1.2.20 is here. This bugfix and tooling update for Kotlin 1.2 is compatible with all versions of IntelliJ IDEA from 2017.1 until 2017.3, and also with Android Studio 3.0 and 3.1 Canary.

Dmitry Jemerov, Principal Engineer at JetBrains wrote in the blog post announcing the update that it:

  • Adds support for Gradle build cache
  • Improves incremental compilation for Android and mixed Kotlin/Java projects
  • Provides IDE support for the new Kotlin style guide
  • Adds inlay hints in the editor for implicit parameters and receivers of lambdas, as well as values returned from lambdas
  • Supports development mode in JavaScript DCE Gradle task
  • Introduces new inspections, performance improvements and bug fixes in the IntelliJ plugin

Check out the changelog if you’re interested in the complete list of changes.

SEE ALSO: Kotlin 1.2: Multiplatform projects across the JVM and JavaScript

Compilation performance improvements

In this update, most of the improvements are related to the Gradle plugin. Speaking of, one of the improvements is the support for Gradle build cache.

If you’re using Gradle 4.3 or newer and the build cache is enabled (it’s not by default, requires --build-cache or org.gradle.caching=true), the plugin will reuse compilation results from previous executions of the Kotlin compile task, Jemerov explained.

As mentioned above, “build caching for Kotlin annotation processors is disabled by default because the dependencies of annotation processors cannot be tracked precisely by Gradle, so it may incorrectly reuse results of a previous execution of an annotation processor.”

If you want to enable it anyway, all you need to do is add these lines to the build script:

`kapt {
    useBuildCache = true

Another improvement is more precise tracking of changes in Java files, which allows you to avoid Kotlin recompilation when the changes in Java do not affect Kotlin code.

Keep in mind that this feature is experimental, so you’ll have to add this line to your file if you want to enable it:


Last but not least, changes to Android layout XML files no longer cause recompilation of all Kotlin sources. As of now, only Kotlin files that reference properties generated by Kotlin Android Extensions (*) are recompiled.

The formatter fully supports the new Kotlin style guide

new official Kotlin style guide was recently released, covering the formatting of Kotlin code and the idiomatic use of language and library features. As of now, the formatter fully supports the new style guide. Plus, IntelliJ IDEA inspections can detect (and correct with quick fixes) many style guide violations can be detected.

Keep in mind that the formatting suggested by the new style guide is different from the default formatting previously used by the Kotlin plugin so you’ll have to apply the new guide explicitly in order to avoid unwanted formatting changes. To do that, go to Settings | Editor | Code Style | Kotlin and use the “Set from…” link to choose the code style.

JavaScript DCE development mode

The JavaScript dead code elimination (DCE) plugin will come in handy if you need to reduce the output size of the Kotlin to JavaScript compiler. The DCE process takes a bit of extra time, Jemerov warned, and the output size doesn’t matter during development, so you can now disable dead code elimination.

In order to do that, you’ll have to use the following option:

runDceKotlinJs.dceOptions.devMode = true 

Check out Dmitry Jemerov’s blog post for the complete list of highlights.

Gabriela Motroc
Gabriela Motroc is editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Leave a Reply

Be the First to Comment!

Notify of