More bug fixes and tooling updates

Kotlin 1.0.5: The journey continues

JAXenter Editorial Team
Kotlin 1.0.5

Although Kotlin 1.0.5 continues the list of bug fixes and tooling updates for Kotlin 1.0, there are some interesting changes such as loop to lambda conversion, postfix code completion, new refactorings as well as Android IDE and JavaScript support improvements.

Dmitry Jemerov, principal engineer at JetBrains, announced the release of Kotlin 1.0.5 in a blog post and acknowledged that it basically “continues the series of bugfix and tooling updates for Kotlin 1.0.”

You can find the entire list of fixes and improvements here.

Changes to Kotlin 1.0.5

Loop to lambda conversion is among the changes; the IntelliJ IDEA plugin can identify many cases where imperative for loops can be rewritten in a more idiomatic and compact way using standard library functions such as filter and map. As an example, this:

Screen Shot 2016-11-09 at 10.10.52 AM


is automatically converted into this.

Screen Shot 2016-11-09 at 10.10.59 AM


If you want to trigger the conversion, all you need to do is put the caret on the for keyword and press Alt-Enter.

Postfix code completion is now supported for Kotlin and there are lots of templates. However, it is worth mentioning that this feature is unavailable in Android Studio 2.2 because it depends on platform changes made in IntelliJ IDEA 2016.2. Good news, though prefix code completion will be supported in newer versions of Android Studio based on newer IntelliJ Platform versions.

SEE ALSO: Why Kotlin is the next big thing for Java developers

“Extract Interface” and “Extract Superclass” refactorings are also supported — they were previously supported just for Java and some other languages. The Kotlin plugin also supports a new refactoring “Introduce Type Parameter”, thus offering an easy way to change a class or function into a generic one.

This release also updates the Kotlin Lint checks to feature parity with Android Studio 2.2’s Java Lint checks and adds the “Extract string resource” intention; users can now move a hard-coded string literal from Kotlin code to a string resource file. As far as the JavaScript backend is concerned, there are two new major features:

  • You can now use the @JsName annotation to control the names of JavaScript functions and properties generated from Kotlin code, thus making it easier to call Kotlin-compiled code from plain JavaScript;
  • Class literals (Foo::class) are now supported. However, the value of a ::class expression only defines a simpleName property to access the class name — it does not implement the full KClass API.

Check out the previous release here.

Inline Feedbacks
View all comments