AppCode
CLion
DataGrip
GoLand
IntelliJ IDEA
MPS
PhpStorm
PyCharm
Rider
RubyMine
WebStorm
Toolbox App
.NET Tools
ReSharper C++
Space
TeamCity
Upsource
YouTrack
HubKotlin 1.1.60 is out
We’re happy to announce the release of Kotlin 1.1.60, a new bugfix and tooling update for Kotlin 1.1. This update:
- Adds experimental support for Kotlin/JS incremental compilation
- Adds new features to JSR-305 custom nullability annotations support
- Brings a lot of bug fixes in the automatic
Parcelableimplementation generator and provides it with IDE support - Improves Gradle incremental builds
- Introduces new inspections, performance improvements and bug fixes in the IntelliJ plugin
The update is compatible with all versions of IntelliJ IDEA from 2016.3 until 2017.3, as well as with Android Studio 2.3, 3.0 and 3.1 Canary.
The complete list of changes in this release can be found in the changelog.
We’d like to thank our external contributors whose pull requests were included in this release: Toshiaki Kameyama, Kirill Rakhman, Paul Merlin, Raluca Sauciuc, Yoshinori Isogai, Andrey Mischenko, Francesco Vasco, Jonathan Leitschuh, Denis Grachev, and pivotal-vladimir.
Kotlin/JS Incremental Compilation
Kotlin 1.1.60 introduces experimental support for incremental compilation in Kotlin/JS Gradle projects, which can significantly reduce build times during development, with compilation of a small local change taking seconds instead of a minute for a full non-incremental rebuild.
It is disabled by default and should be enabled by setting kotlin.incremental.js=true in gradle.properties or local.properties.
Feel free to try it out and report any issues you encounter to the Kotlin issue tracker.
JSR-305 Support
The support for JSR-305 nullability annotations, which was extended by type qualifier nicknames and defaults in Kotlin 1.1.50 , has been further improved and received bug fixes in this release.
Type qualifier defaults for all type usages
The JSR-305 default type qualifiers can now specify ElementType.TYPE_USE to affect all type usages within the annotated scope, including type arguments, upper bounds of type parameters and wildcard types:
@Nonnull(when = When.MAYBE)
@TypeQualifierDefault({ElementType.TYPE_USE})
public @interface NullableApi {
}
@NullableApi
interface Foo<T extends Bar> { // Upper bound T : Bar? in Kotlin
List<String> baz(List<? extends Qux> qux);
// in Kotlin: fun baz(qux: List<out Qux?>?): List<String?>?
}
Migration status of custom nullability annotations
Library maintainers who provide type qualifier nickname and type qualifier default annotations can now control the migration status of the annotations by marking the annotation types with @UnderMigration. This annotation is shipped in a new artifact kotlin-annotations-jvm that should be added as a dependency for the library, e.g compile "org.jetbrains.kotlin:kotlin-annotations-jvm:1.1.60" in Gradle.
The @UnderMigration(status = ...) value specifies how the compiler treats nullability violations detected in the annotated API usages and can be one of MigrationStatus.STRICT, MigrationStatus.WARN and MigrationStatus.IGNORE, making the compiler produce errors, warnings or neither respectively.
Note: MigrationStatus.STRICT is now considered experimental in the sense that there are no guarantees for code compiled in current version with this option to be still correct with the future Kotlin versions. It’s very likely that the checks will be more strict in Kotlin 1.2.x or Kotlin 1.3.
Compiler flags for migration status control
Library users who, for some reason, need a migration status different from that offered by a library maintainer can set up the nullability checks by passing the compiler flags in one of the forms:
-Xjsr305={strict|warn|ignore}that now only affects all annotations which do not have an@UnderMigrationstatus-Xjsr305=under-migration:{strict|warn|ignore}overrides the behavior of all@UnderMigrationannotations-Xjsr305=@<fq.name>:{strict|warn|ignore}wherefq.nameis a fully qualified name of a specific annotation to override the migration status
The strict mode is experimental, too, and provides no guarantees for sources compiled with Kotlin 1.1.60 to compile with the future versions.
These flags can be combined, for example, -Xjsr305=ignore -Xjsr305=under-migration:ignore -Xjsr305=@org.library.MyNullable:warn makes the compiler ignore all nullability annotations but org.library.MyNullable and report warnings for the latter.
Parcelable Support
This release fixes a lot of known issues in the experimental automatic Parcelable implementation generator that was presented in Kotlin 1.1.4 (see the specification) and also provides IDE support in the form of diagnostics and quick fixes aimed to help with using @Parcelize.
Gradle Incremental Builds
With Kotlin 1.1.60, the Kotlin code in the test source set of a Gradle project is re-compiled incrementally whenever the main sources are changed.
Also, a few bug fixes make the up-to-date checks more reliable to make sure the code is re-compiled whenever such options as JVM target, compiler plugins configuration and others change.
IntelliJ IDEA Plugin Improvements
The new release brings a lot of improvements in the Kotlin IntelliJ IDEA plugin:
- New project wizard to create a Gradle project with Kotlin DSL
- A quick fix to convert
Iterable,SequenceandArrayinto each other in case of type mismatch - A quick fix to make a type parameter reified when that is required by its usage
- A lot of bug fixes and performance improvements
How to update
To update the plugin, use Tools | Kotlin | Configure Kotlin Plugin Updates and press the “Check for updates now” button (for Android Studio 3.1, download the plugin from a separate channel at the Plugin Repository). 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!
Alex Martsinovich says:
May 16, 2017Thanks Guys!
Pavel Sikun says:
May 16, 2017Agree regarding to shape, but I think colors are the best way to set identity of a user group. So like country-specific user groups can color logo into colors of their country’s flag. Simple text line below standard blue logo is really boring and uninspiring.
P.S. When can we expect to see kotlin survey results? It’s been almost a month since previously announced date 🙁
Alina Dolgikh says:
May 19, 2017Hello, Pavel! Your concern is totally reasonable. We were puzzled with almost the same question and I will explain why. On the one hand the logo should stay static and recognizable for different groups and situations; on the other hand, specific groups might want to add some adornments and change something in its style. So we are asking not to change it radically: the logo should still stay recognizable after the changes. So please add your fine tuning but let the logo stay recognizable.
Regarding the survey results. I’m very sorry for the delay with the publication of the results. We are still working on it. The report will be prepared by Andrey Breslav and at the moment he has a few urgent tasks that are mandatory. Sorry for this one more time.
Guy Heylens says:
May 16, 2017Nice style! Finished adjusting the website http://www.kotlin.be and our meetup group. https://www.meetup.com/Kotlin-user-group-belgium/#
Abdellah SELASSI says:
May 17, 2017Good job Alina I was wondering something similar … and you just did it !
Andy Bowes says:
May 17, 2017Thanks, that looks great.
So that I can keep our UG logo consistent, what font have you used on the User Group Logo?
Eduardo Medina says:
May 21, 2017Thanks for the new design. Which is the font or typography?
Oliver Nautsch says:
June 15, 2017Thanks for the work! What do you think about this “fine tuning”? https://www.meetup.com/Kotlin-Swiss-User-Group/
Alina Dolgikh says:
June 20, 2017Hi! It looks really nice 🙂
Thanks!
Anindya Chatterjee says:
November 14, 2017This new kotlin plugin still did not resolve an annoying kapt bug I reported here – https://youtrack.jetbrains.com/issue/KT-19325 and the related one https://youtrack.jetbrains.com/issue/KT-19823. The issue is said to be fixed, but I am not getting expected result. I still don’t understand the rationale behind the changes between kotlin gradle build plugin and IDEA plugin.
Shiran says:
November 14, 2017In the main gradle file, on the:
classpath “org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version”
I get a warning:
“Kotlin version that is used for building with Gradle (1.1.60) differs from the one bundled into the IDE plugin (1.1.51)”
Should i just ignore it?
Is it an AS bug for displaying this?
Dmitry Jemerov says:
November 14, 2017This message means that you updated the plugin version in Gradle but not in Android Studio. To update the plugin in Android Studio, go to Tools | Kotlin | Configure Kotlin Plugin Updates and press “Check for updates now”.
Michal Adamsky says:
November 15, 2017I have a new version of plugin, updated plugin in build.gradle, and experiencing same issue.
Dev Landing says:
November 14, 2017Nice that you fixed a lot of the Parcelable bugs!! Parcelable has to be one of my favorite improvements upon Android.
Cristan Meijer says:
November 15, 2017@Parcelize is awesome indeed! I now use it instead of @PaperParcel, so I have 267 usages already 😀
Too bad the IDE still complains though:
https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FKT-19300
Cristan Meijer says:
November 17, 2017-edit: Parcelize turned out to be not so awesome after all, since it doesn’t work properly on older Android devices: https://youtrack.jetbrains.com/issue/KT-20928
Zac Sweers says:
November 16, 2017has there been any update on why the
kotlin-annotation-processingartifact for 1.1.60 was pulled?Dmitry Jemerov says:
November 16, 2017It’s now available as
kotlin-annotation-processing-gradle.babak says:
November 16, 2017hi
since last update to 1.1.60 antd gradle to 4.1.1 in android studio 3.0.1 I cant build my project and always says somthin bball like read doctype or unable resolve test….
Dmitry Jemerov says:
November 17, 2017Please show the specific error message you’re getting; otherwise we can’t do much to help.
cyril says:
November 19, 2017Hello, I use AS 3.0.1 Canary 4, with Kotlin 1.1.60. My “performing code analysis” is very slow, not to say “stuck”. I rebuild project, clean project, invalidate cache and restarted many times. I disabled instantrun too, but nothing to do, my analysis are stuck. It happened only after I changed to Kotlin 1.1.60. Could you help please, or do I just have to wait next release ?
cyril says:
November 19, 2017Sorry, I meant AS 3.1 Canary 4.
Dmitry Jemerov says:
November 20, 2017If you’re using AS 3.1 Canary, you need to get this version of the plugin: https://plugins.jetbrains.com/plugin/download?updateId=40489
Uninstall the plugin from Settings | Plugins, then download the file from the link above and use “Install plugin from disk” to install it.
Alexander Orlov says:
November 22, 2017I switched from v1.1.51 to v1.1.60 and suddenly Gradle 4.3.1 cannot compile the project without providing any meaningful error message. If there were some tooling / instrumentation / integration related change… those changes need to be communicated much better than feature changes 😉
Dmitry Jemerov says:
November 22, 2017There were no intentional changes that could lead to this behavior. Can you run Gradle with –debug and file a YouTrack issue with the relevant part of the log attached?
Alexander Orlov says:
November 24, 2017Might be my Windows’ fault. After Windows crashed and restarted, everything worked fine. I think it was some odd Gradle locking issue on Windows as –debug and –stacktrace did not revealed anything bu the most generic Gradle exception.