Kotlin 1.1.50 is out


We’re happy to announce the release of Kotlin 1.1.50, a new bugfix and tooling update for Kotlin 1.1. This update:

  • Introduces a new versioning scheme: 1.1.5x instead of 1.1.5-x
  • Improves support for JSR-305 annotations (nullability problems can be reported as warnings, checks work when JSR-305 classes are not on the classpath)
  • Improves generated bytecode performance
  • Enables primitive array to TypedArray translation, adds source maps support to the dead code elimination tool and makes other improvements for the JS backend
  • Fixes lots of bugs in the compiler and IDE
  • Introduces new inspections, performance improvements and bugfixes in the IntelliJ plugin
  • Supports extension points for preview of the Kotlin serialization 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 and 3.0.

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: Andrius Semionovas, Dimach, Kirill Rakhman, Toshiaki Kameyama, scache, André Oriani, Daniil Vodopian, Nagesh Susarla, and Knize.

Versioning scheme change

Starting with this release instead of using versions 1.1.5, 1.1.5-1, 1.1.5-2, etc. versions 1.1.50, 1.1.51, 1.1.52 will be used.

We want to publish our JS artifacts to NPM with the same version number as the version of the release. The issue here is that we use the number after that dash as the hotfix number, while NPM considering versions with the dash as being pre-release. This means that NPM considers Kotlin 1.1.5 to be more recent than 1.1.5-1, whereas the opposite is actually true. Changing the versioning scheme fixes the problem.

JSR-305 annotation support improvements

Kotlin 1.1.4 introduced initial experimental support for default nullability annotations, such as @ParametersAreNonnullByDefault as an opt-in feature. In Kotlin 1.1.50, nullability problems detected thanks to such annotations are by default reported as warnings. To convert them into errors, add the command line parameter -Xjsr305=strict. To disable the warnings, use -Xjsr305=ignore. (Note that the command line parameter -Xjsr305-annotations=enable, which was used to enable default nullability annotations in Kotlin 1.1.4, is now deprecated.)

Also, since this release, Kotlin no longer requires having a .jar file with JSR-305 annotations in the dependencies of a library in order to read the nullability information for this library.

Note that the strict mode JSR-305 support in the compiler is an experimental feature.

JavaScript backend improvements

Kotlin 1.1.50 introduces several changes which break binary forward compatibility for the JavaScript backend. This means that you should update your compiler to 1.1.50 or newer if you want to use libraries compiled with Kotlin/JS 1.1.50. You can still use libraries compiled with older version of Kotlin compiler.

Inliner improvements

The way inline functions are translated to JS has been changed in order avoid using fully qualified names in the inlined function bodies. This reduces the size of the resulting JS file.

TypedArrays enabled by default

Primitive arrays are translated to TypedArrays by default now. This feature can be disabled by passing -Xtypedarrays=false to the compiler. This change affects binary forward compatibility – using old compiler with new libraries is discouraged.

Note that the new array representation may also affect calling JS code from Kotlin. To call a JS function that expects a regular Array and not a TypedArray, use toTypedArray extension function to convert a TypedArray to a regular Array. Functions like toIntArray could be used to convert a regular Array of primitives to a TypedArray.

This change also makes it possible to distinguish between Array and IntArray and the like at runtime.

Source maps support in DCE

Kotlin 1.1.50 improves the dead code elimination tool making it easier to debug its output. The tool detects existing sourcemaps and transforms them alongside with the code. See the tutorial to learn more about JS debugging.

IntelliJ IDEA plugin improvements

The new release brings many improvements to the IntelliJ IDEA plugin:

  • Performance improvements
  • Support for code completion of import aliases
  • Better support for Gradle Kotlin DSL
  • Inspections to verify that the code matches the formatting and naming conventions configured for the project
  • Many other new inspections and quickfixes

How to update

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

13 Responses to Kotlin 1.1.50 is out

  1. Evan Nelson says:

    Why 1.1.5x instead of 1.1.5.x?

  2. Arbot says:

    This versioning feels really confusing to me. Why not 1.1.5.0? What happens if you need a release between 1.1.59 and 1.1.60?

    • Dmitry Jemerov says:

      The last digit in the version number represents the hotfix number. If we ever find ourselves in a situation where we need more than 9 hotfixes to get a release right, this will mean that something is really badly broken in our release process, and version numbers will not be our biggest concern at that point.

  3. Pablo says:

    Guys, I do also find this versioning scheme strange.
    As to my point of view, either 1.1.5.x or 1.1.5-x, but in no case 1.1.5x.
    Hope you’ll change it.

    • Dmitry Jemerov says:

      As we explained, the decision to change the versioning scheme was not driven by our perception of whether it is strange or not, but by the requirements of the various services that Kotlin integrates with (npm and additionally OSGi). We won’t change the versioning scheme unless either we come up with a different way of numbering versions that maintains compatibility (which we consider to be unlikely), or the requirements of some of those services are relaxed.

      • Does NPM not allow for 1.1.5.x?

        • Bughunter says:

          NPM uses semver and does not allow a 4th field. And it uses the characters after “-” for prereleases.
          But there is also a statement from the semver developer: there is really not need for hotfix versions. Simply increment the patch number.
          If jetbrains uses the 3rd field for something different, it would not be semver compatible too.

  4. citygm says:

    How about using 1.1.5004323423 as your .
    The two digital number may not be enough for you to fix bugs and release.
    or how to deal with it if reach 1.1.59
    next version 1.1.60? or 1.1.59-1?
    stupid…

  5. Cristan Meijer says:

    I’m curious why you haven’t chosen for actual semantic versioning. So instead of 1.1.50, it would be 1.5.0 and any patches would be 1.5.1 etc.

  6. Eugen says:

    For anyone still bitching about this, kindly read about Bikeshedding here:
    https://en.wiktionary.org/wiki/bikeshedding

  7. Player2 says:

    So many comments about the version number. How in the world any numbering will help as a developer. It is good as long it is different from previous one. Why not just focus on things that matter.

Comments are closed.