Kotlin 1.2.40 is out!

Posted on April 19, 2018 by yanex

We’re happy to announce the release of Kotlin 1.2.40, a new bugfix and tooling update for Kotlin 1.2! This update:

  • Allows platform modules in experimental multiplatform projects to have more than one expectedBy dependency;
  • Enables support for crossinline suspend parameters in inline functions;
  • @JvmDefault annotation that makes interface methods default in Java (experimental);
  • Adds new inspections and intentions to the Kotlin IntelliJ plugin;
  • Deprecates using short names of types brought into the scope through subtyping of companion objects, without qualifying or importing them;
  • Fixes a lot of known issues in the compiler and the IDE plugin and provides performance improvements.

The update is compatible with all versions of IntelliJ IDEA from 2017.1 until 2018.1, as well as with Android Studio 3.0, 3.1, and 3.2 Canary.

We’d like to thank our external contributors whose pull requests were included in this release: Toshiaki Kameyama, Mikaël Peltier, Alexey Belkov, meztihn, Gaetan Zoritchak, Yoshinori Isogai, Cuihtlauac Alvarado, Egor Neliuba, Elifarley C., Felix Guo, Jake Wharton, Raluca Sauciuc, Renaud Paquay, Rodrigo B. de Oliveira, Valeriy Zhirnov, Yanis Batura, Yuta Sakata, Kenji Tomita, yukuku.

The complete list of changes in this release can be found in the changelog.

Improvements for multiplatform projects

This update brings several improvements for the experimental multiplatform projects feature.

Platform modules are now allowed to reuse the code and provide actual platform-specific implementations for declarations from more than one common module. This is done by adding multiple expectedBy dependencies to the platform module, for example:

Note that expectedBy dependencies are still non-transitive, so if a common module, say, 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.

Another improvement is the support for default parameters in expect functions and constructors:

Note that default parameter values are only allowed in expect declarations. Do not specify them for the actual counterparts.

Crossinline suspend function parameters

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

Support declaring Java default interface methods

This release brings experimental support for generating default interface methods for the JVM target 1.8 and above. This feature is disabled by default, you can enable it 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):

Since this functionality is experimental in Kotlin 1.2.x, its design and implementation may change in future updates, including the compiler flag name.

Visibility restrictions for types brought into scope through companion objects subtyping

To provide smooth migration with respect to potentially breaking changes in Kotlin 1.3 regarding classifiers visible through companion objects, this update introduces deprecation warnings and migration tools in the IDE plugin.

Now, whenever a body of a type Foo uses a short (non-qualified) type name that 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, a warning is issued with a quick-fix that adds the import. One example is:

In Kotlin 1.3, these short names are going to become invisible unless they are qualified or imported. The planned change has been tested on real projects with more than 1.5 million lines of Kotlin code in total, and the impact is expected to be minimal.

For detailed description and motivation of the change, see KT-21515.

IntelliJ IDEA plugin improvements

Intentions for adding and removing explicit return in a lambda

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

Other changes in the IDE plugin

  • New intentions for adding and removing annotation use-site targets;
  • An inspection to highlight and remove unnecessary explicit companion object references;
  • A lot of stability and performance improvements.

Changes in the compiler

The Kotlin 1.2.40 update fixes several known issues in the Kotlin compiler and includes performance improvements.

The code that the compiler generates is now more efficient in several cases, such as accessing private properties of companion objects, checking enum entries for equality, and comparing Long numbers, thanks to our contributor Mikaël Peltier.

How to update

To update the plugin, use Tools → Kotlin → Configure Kotlin Plugin Updates and press the Check for updates now button. Also, don’t forget to update the compiler and standard library version in your Maven and Gradle build scripts.

As usual, if you run into any problems with the new release, you’re welcome to ask for help on the forums, on Slack (get an invite here), or to report issues in the issue tracker.

Let’s Kotlin!

This entry was posted in Releases and tagged . Bookmark the permalink.

21 Responses to Kotlin 1.2.40 is out!

  1. Erik says:
    April 20, 2018 at 12:00 am

    Noticed the new scratch file for Kotlin. Coming from
    Swift I really miss the interactive playgrounds. Could you elaborate on the scratch file functionality for KOTLIN. Congrats on a new release!

    • yanex says:
      April 20, 2018 at 12:06 am

      Thank you!
      We continue working on scratch file functionality, and I hope we will have a number of enhancements in the upcoming releases.

  2. Arun says:
    April 20, 2018 at 3:29 am

    Unable to download the 1.2.40 kotlin compiler from the github release page…
    Even sdkman is giving the following error,

    sdk install kotlin ~/IdeaProjects/kotlin/neverEnding

    Downloading: kotlin 1.2.40

    In progress…

    ######################################################################## 100.0%
    curl: (6) Could not resolve host: github-production-release-asset-2e65be.s3.amazonaws.com
    End-of-central-directory signature not found. Either this file is not
    a zipfile, or it constitutes one disk of a multi-part archive. In the
    latter case the central directory and zipfile comment will be found on
    the last disk(s) of this archive.
    unzip: cannot find zipfile directory in one of /Users/arun/.sdkman/archives/kotlin-1.2.40.zip or
    /Users/arun/.sdkman/archives/kotlin-1.2.40.zip.zip, and cannot find /Users/arun/.sdkman/archives/kotlin-1.2.40.zip.ZIP, period.

    Stop! The archive was corrupt and has been removed! Please try installing again.

    Please fix…

  3. Chris Rankin says:
    April 20, 2018 at 1:12 pm

    Nice to see the new (experimental) @JvmDefault feature, but -Xenable-jvm-default is for the command-line compiler. How would I enable this feature using the Gradle plugin please? The ExperimentalExtension is still implemented as:

    • Mikhael Bogdanov says:
      April 20, 2018 at 4:21 pm

      or

      • Chris Rankin says:
        April 24, 2018 at 3:22 pm

        Thanks, that works. I’m hoping that @JvmDefault will simplify our ProGuard configuration because we will no longer need to list all of the $DefaultImpls classes that we’re interested in keeping by hand.

  4. Munya says:
    April 20, 2018 at 6:54 pm

    The default behaviour when a Kotlin interface is implemented in Java code caught me out

    // Kotlin
    interface Foo {
    fun boo() { println(“hoo”) }
    }

    // Java
    class JavaFoo implements Foo {

    // Error you need to implement Foo::boo

    }

    Is there a reason why these aren’t marked “default” by default?

  6. Nhat Nguyen says:
    April 24, 2018 at 12:13 pm

    Unable to start : Caused by: java.lang.IllegalStateException: Ambiguous mapping. (Spring Boot Restful & Optional parameter & Kotlin 1.2.40)
    @GetMapping(“/api/carts/pay”)
    fun carts(@RequestParam(“cartId”, required = false) cartId: Int? = null,
    @RequestParam(“langId”) languageId: Int,
    @RequestParam(“ccy”) currency: Currency) {
    return “ok”
    }

    works well with 1.2.31

    • yanex says:
      April 24, 2018 at 6:07 pm

      Can you please provide some kind of a sample project?

      • Nhat Nguyen says:
        April 27, 2018 at 8:21 am

        I forked kotlin-samples and made some changes:
        https://github.com/minhnhat2807/kotlin-examples/commit/e8fa33c9c01ab06250099428d5e6a4103675c577

        Running result:
        Caused by: java.lang.IllegalStateException: Ambiguous mapping. Cannot map ‘greetingController’ method
        public static org.jetbrains.kotlin.demo.Greeting org.jetbrains.kotlin.demo.GreetingController.greetingTest$default(org.jetbrains.kotlin.demo.GreetingController,java.lang.Integer,java.lang.String,int,java.lang.Object)
        to {[/greeting/test],methods=[GET]}: There is already ‘greetingController’ bean method

    • Mattias Fagerström says:
      April 27, 2018 at 3:41 pm

      I’m having a similar issue with Ambiguous mapping in Spring Boot that works with 1.2.31

      This works in 1.2.31, but not in 1.2.40:
      @PostMapping(“/test”)
      fun test(@RequestParam arg1: String, @RequestParam arg2: Boolean = false): String {
      return “OK”
      }

      Solution that also works in 1.2.40:
      @PostMapping(“/test”)
      fun test(@RequestParam arg1: String, @RequestParam(defaultValue = “false”) arg2: Boolean): String {
      return “OK”
      }

  7. Bernd says:
    April 24, 2018 at 3:19 pm

    Every common platform module generates a META-INF/main.kotlin_module file. Is it intended behaviour, that it is always called “main” now, even if “archivesBaseName” is explicitly specified in the gradle file? It can cause problems because of duplicate entries.

Comments are closed.