Kotlin 1.0.6 is here!

We are happy to announce the release of Kotlin 1.0.6, the new bugfix and tooling update for Kotlin 1.0. This version brings a significant number of improvements related to the IDE plugin and Android support.

We’d like to thank our external contributors whose pull requests are included in this release: Kirill Rakhman and Yoshinori Isogai. We also want to thank everyone of our EAP users for their feedback. It is really valuable for us, as always.

You can find the full list of changes in the changelog. Some of the changes worth highlighting are described below.

Convert try-finally to use() intention

We continue to add intentions for converting code to idiomatic Kotlin. The IDE now automatically suggests to replace try-finally block with the use() call when all the finally block does is closing a resource.

“Add names to call arguments” intention

Named arguments help to increase code readability. With the new “Add names to call arguments” intention you can easily add the name to an argument, or just substitute names for all call arguments at once.

Other notable IDE plugin changes

  • Inspection/intention for removing empty secondary constructor body, as well as empty primary constructor declaration;
  • “Join declaration and assignment” intention;
  • Fixes for inline functions and performance improvements in debugger;
  • Numerous fixes in intentions, KDoc and Quick Doc.

Android Support

  • Android Studio 2.3 beta 1 is now supported, as well as the Android Gradle plugin version 2.3.0-alpha3 and newer.
  • “Create XML resource” intention is added;
  • Android Extensions support is now active in the IDE only if the corresponding plugin is enabled in the build.gradle;
  • Significant number of fixes in Android Lint. Also the “Suppress Lint” intention is added.

Kapt Improvements

We continue to work on the experimental version of Kotlin annotation processing tool (kapt). While there are still some things to do in order to fully support incremental compilation, performance of the annotation processing is significantly increased since Kotlin 1.0.4.

To enable experimental kapt, just add the following line to your build.gradle:

apply plugin: 'kotlin-kapt'

All-open compiler plugin

The all-open compiler plugin makes classes annotated with a specific annotation and their members open without the explicit open keyword, so it becomes much easier to use frameworks/libraries such as Spring AOP or Mockito. You can read the detailed information about all-open in the corresponding KEEP.

We provide all-open plugin support both for Gradle and Maven, as well as the IDE integration.

How to use all-open with Gradle

If the class (or any of its superclasses) is annotated with com.your.Annotation, the class itself and all its members will become open. It even works with meta-annotations:

We also provide the “kotlin-spring” plugin that already has all required annotations for the Spring framework:

Of course, you can use both kotlin-allopen and kotlin-spring in the same project.

How to use all-open with Maven

No-arg compiler plugin

The no-arg compiler plugin generates an additional zero-argument constructor for classes with a specific annotation. The generated constructor is synthetic so it can’t be directly called from Java or Kotlin, but it can be called using reflection. You can see motivating discussion here.

How to use no-arg in Gradle

The usage is pretty similar to all-open.

How to use no-arg in Maven

How to update

To update the IDEA 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.

The command-line compiler can be downloaded from the Github release page.

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.

30 Responses to Kotlin 1.0.6 is here!

  1. Pingback: Интересные материалы для Android-разработчика: неделя #52 - Подкасты Android Dev

  2. Dude says:

    What about the eclipse integration? Does it support these features too?

  3. Max says:

    Can you link to the release, i.e. https://github.com/JetBrains/kotlin/releases/tag/v1.0.6 ? Like the 1.1-M04 post does.

  4. Tibor Kaputa says:

    Hey, any news about Instant run? The last version in which it works for me is 1.0.3, I’m using the latest Android Studio. Or am I missing something?

  5. Michael Richardson says:

    I’m getting an error with Dagger 2 in an Android project with the straight upgrade to from 1.0.5-3 to 1.0.6:
    Error:(6, 23) Unresolved reference: DaggerTestComponent

    This is in a small test project, which I can send to you.

  6. RodrigoDev says:

    Any way to specify annotations for the generated zero-arguments constructor?

    • yanex says:

      Not yet. By the way, for what framework do you need this?

      • RodrigoDev says:

        Hmm… I thought I was gonna need it for Spring/MongoDB when having more than 1 constructor in a class, but it doesn’t seem to be the case anymore (before I needed to specify @PersistenceConstructor for zero-arguments constructor on such classes, but it seems they are now automatically picked by the framework).

        In any case, I’m kind of getting random results where the framework is not always hable to find the generated zero-args construtor (I tested it on a class that uses inheritance, so let’s say I have base-class->parent->child where parent and child have a synthetic zero-args constructor generated). This happens when compiling the code using IntelliJ instead of Gradle.

        Also, I wasn’t able to make it work with third-party annotations (such as @Document, which is used by Spring Data MongoDB).

        Other problems I found where (using the base-class->parent->child example mentioned before):

        The zero-args constructor on Parent wasn’t able to find the zero-args constructor in the base class when defining a constructor in the base class with default values for all the arguments (therefore having zero-args constructor generated by the compiler).
        The generated zero-args constructor on Parent doesn’t seem to initialize any of the delegate$ fields (therefore causing NullPointerExceptions when trying to access delegated properties).

        PS: If I get time some time, I’ll try to properly report these issues in the issue tracker.

        • Tim van der Leeuw says:

          The solution for me was to tell IntelliJ to use Gradle for it’s own build process.

          I don’t know if that’ll work when one wants to use Maven instead – is there a similar option for Maven? I didn’t see one.

  7. Tim van der Leeuw says:

    I have added the kotlin-spring plugin to my Gradle build files and it appears to work, but now the project is broken when IntelliJ executes a build – classes that should be open, no longer are.

    I’ve tried to figure out how to add these annotation processors to the build in IntelliJ compiler settings or Kotlin Facet settings but haven’t worked out yet how to do that?

    (I guess RodrigoDev has the same issue).

    Any help would be appreciated!

  8. Kazuki Shimizu says:

    I used the all-open(spring extension) with Maven. A Maven build work fine. But execution on IntelliJ IDEA does not work … :(

    Cloud you help us ?

    • Tim van der Leeuw says:

      I believe that there is no solution other than to move your build system over to Gradle, and delegating IntelliJ build actions to Gradle… :-(

      See also:


      IDEA doesn’t support the annotation processing, and fixing this is not a priority for JetBrains.

      Since I was using Gradle already it was not a big obstacle to me but when using Maven, it will be quite a pain – it means having to execute mvn compile every time after making any change to your code that you want to execute.

      I guess you could disable auto-compilation in the IDEA settings and change your run-configurations to execute “mvn compile” before executing the requested test or application code, instead of doing a Make.

      I can understand why JetBrains doesn’t want to prioritize updating JPS – any build system that’s internal to and specific to an IDE is a pain because it will eventually run out of sync with your standalone build scripts.
      But they should then give more priority to making Maven a first-class citizen, like they do with Gradle.

      (I’d say that NetBeans Maven support is first-class and has long been an example for other IDE’s but Kotlin support in NetBeans isn’t all that great to my knowledge.)

  9. Tim van der Leeuw says:

    IntelliJ has a lot of helpful warnings for classes and methods which should be marked “open” when certain Spring annotations are present.
    However, now that I’ve applied the kotlin-spring plugin, these warnings no longer make sense.

    It would be nice if IntelliJ could automatically detect the use of this plugin in a project and disable these warnings for that case (like it automatically detects when the version of Kotlin used in a project doesn’t match the Kotlin plugin version).

  10. Pingback: Introducing Kotlin support in Spring Framework 5.0 | Alexius DIAKOGIANNIS

  11. Václav says:

    do you have any plans to enable no args generation for data classes in kotlin-maven-noarg?

    • It looks like too much to give no-arg constructors to all data classes. Why not to all classes, then?

      Anyway, does annotating those data classes not work for your use case?

  12. Pingback: 在Spring Framework 5.0中引入Kotlin支持 - 莹莹之色

  13. Pingback: Spring Framework 5.0 对 Kotlin 支持的介绍 - 莹莹之色

  14. Serg de Adelantado says:

    Still no in-box support in IDEA for kapt(for example, when using QueryDSL).

  15. Gregor Petrin says:

    Is it possible to only open the classes during the testing phase so we can create mocks and stubs easily?

  16. Pingback: JVM-Sprache Kotlin: Kotlin 1.0.6 und Vorschau auf Kotlin 1.1 [Update] - JAXenter

Comments are closed.