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.

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

1

2

3

4

5

6

7

8

9

10

11

12

buildscript{

dependencies{

classpath"org.jetbrains.kotlin:kotlin-allopen:$kotlin_version"

}

}

apply plugin:"kotlin-allopen"

allOpen{

annotation("com.your.Annotation")

}

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:

1

2

3

4

5

6

@com.your.Annotation

annotation classMyFrameworkAnnotation

@MyFrameworkAnnotation

classMyClass// will be all-open

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

1

2

3

4

5

6

7

8

buildscript{

dependencies{

classpath"org.jetbrains.kotlin:kotlin-allopen:$kotlin_version"

}

}

apply plugin:"kotlin-spring"

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

How to use all-open with Maven

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

<plugin>

<artifactId>kotlin-maven-plugin</artifactId>

<groupId>org.jetbrains.kotlin</groupId>

<version>${kotlin.version}</version>

<configuration>

<compilerPlugins>

<!--Or"spring"forthe Spring support-->

<plugin>all-open</plugin>

</compilerPlugins>

<pluginOptions>

<!--Eachannotation isplaced on its own line-->

<option>all-open:annotation=com.your.Annotation</option>

<option>all-open:annotation=com.their.AnotherAnnotation</option>

</pluginOptions>

</configuration>

<dependencies>

<dependency>

<groupId>org.jetbrains.kotlin</groupId>

<artifactId>kotlin-maven-allopen</artifactId>

<version>${kotlin.version}</version>

</dependency>

</dependencies>

</plugin>

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.

1

2

3

4

5

6

7

8

9

10

11

12

13

buildscript{

dependencies{

classpath"org.jetbrains.kotlin:kotlin-noarg:$kotlin_version"

}

}

// Or "kotlin-jpa" for the Java Persistence API support

apply plugin:"kotlin-noarg"

noArg{

annotation("com.your.Annotation")

}

How to use no-arg in Maven

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

<plugin>

<artifactId>kotlin-maven-plugin</artifactId>

<groupId>org.jetbrains.kotlin</groupId>

<version>${kotlin.version}</version>

<configuration>

<compilerPlugins>

<!--Or"jpa"forthe Java Persistence annotation support-->

<plugin>no-arg</plugin>

</compilerPlugins>

<pluginOptions>

<option>no-arg:annotation=com.your.Annotation</option>

</pluginOptions>

</configuration>

<dependencies>

<dependency>

<groupId>org.jetbrains.kotlin</groupId>

<artifactId>kotlin-maven-noarg</artifactId>

<version>${kotlin.version}</version>

</dependency>

</dependencies>

</plugin>

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.

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.

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.)

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).