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
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:
@com.your.Annotation annotation class MyFrameworkAnnotation @MyFrameworkAnnotation class MyClass // will be all-open
We also provide the “kotlin-spring” plugin that already has all required annotations for the Spring framework:
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
<plugin>
<artifactId>kotlin-maven-plugin</artifactId>
<groupId>org.jetbrains.kotlin</groupId>
<version>${kotlin.version}</version>
<configuration>
<compilerPlugins>
<!-- Or "spring" for the Spring support -->
<plugin>all-open</plugin>
</compilerPlugins>
<pluginOptions>
<!-- Each annotation is placed 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.
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
<plugin>
<artifactId>kotlin-maven-plugin</artifactId>
<groupId>org.jetbrains.kotlin</groupId>
<version>${kotlin.version}</version>
<configuration>
<compilerPlugins>
<!-- Or "jpa" for the 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.
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!
Dude says:
December 28, 2016What about the eclipse integration? Does it support these features too?
yanex says:
December 28, 2016Unfortunately, not yet. I’ve created an issue for this: https://youtrack.jetbrains.com/issue/KT-15467
Max says:
December 28, 2016Can you link to the release, i.e. https://github.com/JetBrains/kotlin/releases/tag/v1.0.6 ? Like the 1.1-M04 post does.
yanex says:
December 28, 2016Done, thanks!
Tibor Kaputa says:
December 29, 2016Hey, 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?
Mikhael Bogdanov says:
January 9, 2017Could you file issue to http://youtrack.jetbrains.com/issues/KT with build configuration description and/or sample project?
Michael Richardson says:
December 30, 2016I’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.
yanex says:
January 2, 2017Please create the new issue for this in our YouTrack: https://youtrack.jetbrains.com/issues/KT
You can attach the sample project there.
Michael Richardson says:
January 3, 2017I’ve attached my sample project to https://youtrack.jetbrains.com/issue/KT-15459. Thanks.
RodrigoDev says:
December 31, 2016Any way to specify annotations for the generated zero-arguments constructor?
yanex says:
January 2, 2017Not yet. By the way, for what framework do you need this?
RodrigoDev says:
January 2, 2017Hmm… 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:
January 2, 2017The 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.
Tim van der Leeuw says:
January 2, 2017I 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!
Tim van der Leeuw says:
January 3, 2017Fixed the issue by delegating IntelliJ build actions to Gradle, in the Gradle runner settings.
yanex says:
January 9, 2017What Kotlin IDEA plugin version do you use? Is it 1.0.6-release?
Anyway, can you create an issue for this so we could investigate it further?
Tim van der Leeuw says:
January 9, 2017I do use the 1.0.6 version of the plugin, yes.
I will file an issue.
Tim van der Leeuw says:
January 9, 2017Filed as issue KT-15608:
https://youtrack.jetbrains.com/issue/KT-15608
Kazuki Shimizu says:
January 2, 2017I 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:
January 3, 2017I 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:
https://discuss.kotlinlang.org/t/annotation-processing-gradle/1438/5?u=tim_van_der_leeuw.1
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.)
Tim van der Leeuw says:
January 3, 2017IntelliJ 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).
Václav says:
January 5, 2017do you have any plans to enable no args generation for data classes in kotlin-maven-noarg?
Andrey Breslav says:
January 6, 2017It 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?
Serg de Adelantado says:
January 18, 2017Still no in-box support in IDEA for kapt(for example, when using QueryDSL).
Gregor Petrin says:
January 19, 2017Is it possible to only open the classes during the testing phase so we can create mocks and stubs easily?