Kotlin 1.3.20 released

Posted on by Hadi Hariri

We’re happy to announce the release of Kotlin 1.3.20, a new bug fix and tooling update for Kotlin 1.3. In addition to improvements to the compiler and IDE, this version:

  • Allows running Gradle tasks in parallel within a single project
  • Allows building multiplatform projects via Gradle Kotlin DSL
  • Brings improvements for inline classes
  • Introduces a separate command line tool for Kapt
  • Enables incremental compilation for Kotlin/JS by default
  • Brings improvements to Kotlin/Native

As always, we’d like to thank our numerous external contributors. The complete list of changes for this release can be found in the change log. Let’s dive in!

Faster Gradle builds by parallelizing tasks

The Kotlin Gradle plugin can now run tasks in parallel within a project. Parallel execution is supported by using the Gradle Worker API. To make use of this feature, add the following setting to gradle.properties or local.properties file:

This feature is beneficial for projects defining custom source sets, since the compilation of independent source sets can be parallelized. In the case of multiplatform projects, targets for different platforms can also be built in parallel. For Android, the debug and release build types can be compiled in parallel.

We plan to enable the parallel task compilation by default at a later date, so we kindly ask for your feedback. Do let us know if you face any issues.

Multiplatform projects update

We continue working on multiplatform projects and improve different aspects based on your feedback.

Support for Kotlin Gradle DSL

You can now use Kotlin Gradle DSL to build multiplatform projects:

You can check many examples in both Groovy and Kotlin in the documentation.

DSL improvements

The DSL to set up a multiplatform project has been greatly improved and simplified. This blog post contains some highlights in comparison to the previous version. We recommend you read the updated guide for more details and complete samples.

You can now use shorthand for Kotlin dependencies. That is, instead of 'org.jetbrains.kotlin:kotlin-stdlib' you write simply kotlin('stdlib').

In addition, supported targets can be specified directly instead of using the fromPreset function:

Note that if you need it, the previous functionality still exists, using targetFromPreset(...).

You can also independently configure Kotlin/Native binaries like executable files or native libraries. For instance, you can use this to export symbols of certain dependencies to an Objective-C framework.

For more information, please refer to the documentation.

Finally, we’ve also made kotlinOptions available, allowing for easier compiler configuration

All improvements are available both in Groovy and Kotlin DSL.

Android Library (AAR) can be a part of a multiplatform library

You can now publish Android libraries (AAR) as a part of a multiplatform library. This functionality is disabled by default; to enable it, specify the list of the variants that you want to publish in the scope of the Android target:

You can read more about publishing libraries in the documentation.

Improvements for inline classes

Support for inline classes has been significantly improved, and some constraints have been mitigated. For instance, you can now define an inner class inside an inline class. There are also improvements for non-trivial cases, like using inline functions inside inline classes or passing references to inline classes as arguments to inline functions.

You can now also use reflection with inline classes and have access to class literals and javaClass property

There’s also support for call and callBy for functions that have inline class types in their signature. For more information, refer to the corresponding section on the KEEP.


Code contracts

Some time ago we introduced experimental support for contracts, which allows a function to describe its behaviour in a way that the compiler understands. This functionality is now also available in Kotlin/Native.

Better interop

Improved interop including support for more C constructions such as enums with forward declarations, as well as better error reporting for cases of inheritance in Objective-C.

Native frameworks from libraries

With this release, we can now produce Apple frameworks not only from source files but also from Kotlin libraries (i.e. .klib files). This is possible using the -Xexport-library command line option or via Gradle plugins


Apart from reducing the memory footprint and improving runtime performance, this release also brings compiler optimizations for looping over ranges, making iterations much faster.

IntelliJ IDEA support

This release adds new refactorings, inspections, and intentions to the IntelliJ IDEA plugin. We’ll highlight some of them.

Template to generate main without parameters

Since Kotlin 1.3, you can use the main function without parameters. Now, the default ‘main’ live template adds this new version of main.

If you need to pass some arguments, use ‘maina’ live template.

Inspections to improve coroutines code

When working with coroutines, you usually follow certain conventions. For instance, you would add an “Async” suffix to a function returning ‘Deferred’, or define a function either as a suspend one or as an extension to CoroutineScope, but never both at the same time (for more details, check this talk from KotlinConf). IntelliJ IDEA is now aware of these conventions and offers intentions to fix potential issues:

New intention for converting SAM as lambda to an anonymous object

A new intention allows to convert constructs using lambdas with SAM to anonymous objects. For instance

can now be converted automatically by the IDE to

String conversion improvements

‘Convert concatenation to template’ intention is now smarter, meaning

will be converted to

removing the unnecessary .toString() calls on each parameter.

Kapt improvements

Using Kapt from the command line has been simplified, allowing for direct use as a separate command line tool as opposed to having to use it via the compiler:

All kapt-related arguments are now passed as top-level arguments instead of using the verbose syntax:

Note that a new option that shows processor timings (-Kapt-show-processor-timings`) has also been introduced in this release.

Compile avoidance for kapt

We’ve added support for Compile Avoidance for kaptKotlin tasks in Gradle, improving build performance times. It skips annotation processing completely when there are no changes in kapt stubs and only method bodies are changed in dependencies. Setting

in gradle.properties enables it. Note, however, that this setting also turns off the AP discovery in compile classpath, but if you add AP to kapt* configuration, that shouldn’t affect you.

Other notable mentions

In addition to the above, a few more fixes and improvements worth mentioning:

  • Incremental compilation for Kotlin/JS is now stable enough and is enabled by default. If you encounter any issues, we’d appreciate if you report it to us, and in the meantime, you can disable the option:
    • In a Gradle project, add kotlin.incremental.js=false to gradle.properties or local.properties
    • In an IntelliJ IDEA project, go to Settings | Build, Execution, Deployment | Compiler | Kotlin Compiler | Kotlin to JavaScript and uncheck Enable incremental compilation.
  • We now provide a Kotlin BOM (Bill of Materials) file that lists the dependencies used from the org.jetbrains.kotlin group.
  • Stable sorting is now available on all targets. Previously this was an issue when targeting JavaScript.
  • Numerous fixes and improvements in scripting support.
  • Support for MethodHandle and VarHandle in JVM code generation.
  • Modularized artifacts for Kotlin JVM libraries are included.
  • Kotlin/Native will embed bitcode by default for iOS frameworks targets in Gradle projects.
  • Kotlin/Native annotations @ThreadLocal and @SharedImmutable are now accessible from common code (declared as optional expect).

How to update

To update your IntelliJ IDEA or Android Studio plugin, use Tools | Kotlin | Configure Kotlin Plugin Updates and click the “Check for updates now” button. The Eclipse IDE plugin can be installed or updated via the Eclipse Marketplace (Help | Eclipse Marketplace and search for the Kotlin plugin).

Also, don’t forget to update the compiler and standard library versions 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!

External Contributions

Thank you once again to all community contributions for this release. In particular:


We previously stated that it is necessary to enable parallel builds in Gradle using

This is in fact not required, as this would enable cross-project parallelism. Thank you to Cédric Champeau and Eric Wendelin for pointing this out.

Comments below can no longer be edited.

22 Responses to Kotlin 1.3.20 released

  1. Louis CAD says:

    January 23, 2019

    Kudos for the superb release. I can’t wait to update all the projects to it and get serious with multiplatform libraries, so I’ll start the former now, and the latter as soon as I can.

  2. Evan Rittenhouse says:

    January 24, 2019

    Sweet! I’ve been waiting for multiplatform to be available in the Kotlin DSL for a while now. Thanks for the update guys!

  3. Eric Wendelin says:

    January 24, 2019

    I want to make one quick clarification regarding org.gradle.parallel=true even though most of you probably already know: this is completely unrelated to the Worker API.

    org.gradle.parallel=true tells Gradle to build separate Projects of a multi-project build in parallel. The worker API is much finer-grained. I’m sorry the Gradle Worker API docs at https://docs.gradle.org/current/userguide/custom_tasks.html#worker_api didn’t do a better job making this distinction clear.

    I for one am super excited for Kotlin compilation to be executed in parallel.

    TL;DR — Unless the Kotlin team coded it into the Kotlin Gradle Plugin somehow that org.gradle.parallel=true needs to be on, you don’t need it. Just kotlin.parallel.tasks.in.project=true.

  4. Joe says:

    January 24, 2019

    with 1.3.20 I’m seeing the following warning lines when invoking the kotlin-maven-plugin compile goal in mostly kotlin project (see no such lines with 1.3.11):

    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/Class.class; size in bytes: 48707; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/util/Base64.class; size in bytes: 1941; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/ClassLoader.class; size in bytes: 34285; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/CharSequence.class; size in bytes: 2730; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/String.class; size in bytes: 26700; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/util/regex/Pattern.class; size in bytes: 46519; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/io/File.class; size in bytes: 17596; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/Integer.class; size in bytes: 14982; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/nio/Buffer.class; size in bytes: 5709; file type: CLASS

  5. Markus says:

    January 24, 2019

    Is it now possible to release Kotlin native libraries to e.g. bintray and then consume them via Gradle, like I would do on the JVM? That would be great!

  6. ADEF says:

    January 24, 2019

    You seems to add lot of complexity around building

    All you have to do is ditch Java and fix the compiler using AOT compiled language

    When not warmed up, the process takes an eternity to compile

    This is so annoying that made out company use GO instead of java for backend services

    Kotlin is only used for our Android app, and god knows how slow it is…

    We have huge hopes for Kotlin Native, please make programming fun again!

    • jmfayard says:

      January 24, 2019

      Android builds are very slow but I would bet the Kotlin compilation part is only a small part of it. To profile this, you should use the build scan and post the URL

  7. Craig says:

    January 24, 2019

    I’m not seeing any of the class=”kotlin-code” sections in this article…they all have their visibility style set to hidden.

    FWIW, I’m on a Mac. Tried both Safari and Chrome with the same results.

    • Craig says:

      January 24, 2019

      Possibly related: https://unpkg.com/kotlin-playground@1.18.1/index.js returned a 404.

      • vault103 says:

        January 24, 2019

        Same here, on Chrome of Windows 10

    • William Leung says:

      January 24, 2019



  8. Marcel Bradea says:

    February 3, 2019

    What does the roadmap ahead look like?

    I’m really looking forward on when the team’s focus can start to shift away from the multi-platform stuff and get back to core Kotlin language innovation.

    Badly missing:
    – tuples
    – guard statements (with proper forced ‘returns’)
    – conditional statements (if expressions are ugly as it gets… common guys)
    – optional binding (ie: ‘if let x = expression… { . }’ –> the .let library approach was fine for a beta stage of the language, but there really needs to be language-level support for something as fundamental as this)
    – array/dictionary initialization literals (not library-level ‘listOf(..)/mutableListOf(..), mapOf(..) etc.)
    – language-level async support (not library again)

    There is a big theme here where the language has been leading with libraries to prove concepts out (that’s great)…. but lacking the follow-up on adopting what works back into the language itself – so over time Kotlin has been turning into a library bloat instead of continually simplifying, beautifying and advancing. Feels like a big time for a 2.0 push to reel all these things in.


    • alexeybelkov says:

      February 6, 2019

      Thanks for your feedback! We don’t have a roadmap that we can share at the moment, sorry.

  9. Def should be val says:

    February 6, 2019

    def theJsTarget = js('nodeJs')

    def should be val, right?

    • alexeybelkov says:

      February 6, 2019

      No. This is written in Groovy.

  10. Mosna Jamir says:

    February 11, 2019

    I have Error Too
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/Class.class; size in bytes: 48707; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/util/Base64.class; size in bytes: 1941; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/ClassLoader.class; size in bytes: 34285; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/CharSequence.class; size in bytes: 2730; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/String.class; size in bytes: 26700; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/util/regex/Pattern.class; size in bytes: 46519; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/io/File.class; size in bytes: 17596; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/lang/Integer.class; size in bytes: 14982; file type: CLASS
    WARN: Could not read file: /usr/lib/jvm/java-11-openjdk-amd64!/modules/java.base/java/nio/Buffer.class; size in bytes: 5709; file type: CLASS

    • alexeybelkov says:

      February 11, 2019

      This is already fixed in 1.3.21, see comments above.

  11. APko says:

    February 11, 2019

    Sweet! I’ve been waiting for multiplatform to be available in the Kotlin DSL for a while now. Thanks for the update guys!

  12. Michael says:

    February 12, 2019

    the settings in files ‘gradle.properties’ and ‘local.properties’ are blank , is anyone happens ?Errors might be here—-visible = hidden—— ”


  13. Louis CAD says:

    February 16, 2019

    What is “AP” mentioned in the kapt part where the opt-in property can speed compilation up?

    • Alexey Tsvetkov says:

      February 19, 2019

      “AP” stands for annotation processor/processing.
      To disable annotation processor discovery in compile classpath (so processors would be discovered only in annotation processing classpath) and enable Java compile avoidance for “kaptKotlin*” tasks, add:


      to your gradle.properties file.
      The expected effect is that when you only change a method body in a dependency, annotation processing is skipped. Note, that kaptGenerateStubs* tasks are unaffected by this change.


Subscribe for updates