M7 Release Available

Kotlin M7 is here and with it some long awaited features.

Compiler and Language Changes

Inline support

One of the biggest features of M7 is support for inline functions. Kotlin encourages the use of higher-order functions (some people call this “functional style”) which entails extensive use of lambda expressions. Starting with M7, you can declare a higher-order function as “inline” which means that its body will be inlined at the call site along with any lambdas passed to it. This means that the performance penalty of using such functions is next to nothing. For instance, having a for loop as opposed to using forEach and passing a lambda will have very little difference in terms of speed.

Inlining provides benefits such as the number of generated classes, bytecode size, fewer allocations and fewer megamorphic calls, all of which contribute to these performance gains.

Many functions from Kotlin’s standard library are now inlined.

NOTE: If inlining breaks your code (due to compiler bugs, for example), you can switch it off by passing the -inline off command line option to the compiler (see Preferences -> Compiler -> Kotlin Compiler):


toString(), equals() and hashCode() need override directive

When declaring toString(), equals() and hashCode() we now need to prefix them with the override keyword. This is a breaking change from the previous release and applies to all classes. Use the provided quick-fix in the IDE (Alt+Enter on an error) to quickly add “override” to all such methods in project.

“jet” package renamed to “kotlin”

The jet core classes have been renamed to kotlin, which also means that, yes you guessed it, Kotlin is now the official and final name of, well, Kotlin. This is, again, a potentially breaking change. Most imports will happen automatically. In case you encounter any issues, rename the imports manually.

References to local functions

In Kotlin you can reference a function by name using the ::functionName syntax. This is also available now for local functions


[throws] annotation

You can now decorate a function with the throws annotation to indicate what exceptions should be declared by the function when compiled to the JVM.

would be translated to

in Java.

JavaScript enhancements

You can now provide overloaded functions and have them compiled to JavaScript. Kotlin creates new functions with the suffix _1, _2, and so on.

In addition, JavaScript native functions also allow passing extension literals as parameters.

Standard Library

The standard library is being severely reworked. This includes introduction of streams (among other things, this will serve better compatibility with Java 8) and deprecation of some functions.

Some of the redesign has led to breaking changes to the library API. Most of the functionality is still available, but you may need to fix existing code slightly.

IntelliJ IDEA Enhancements

Copy/Paste now inserts imports

When copying and pasting code from one file to another, IntelliJ IDEA will now automatically import any packages required.

Find Usages improvements

Find Usages now covers local classes. In addition you can now see the overrides as well as a hierarchical view of these.

Smart Completion

Enhancements in code completion with support for enums, Java static members as well as anonymous objects.


Refactoring support

Certain rename refactoring such as local variables can now be done in-place without having to use a dialog box.

In-Place Rename Refactoring

Safe Delete

You can now safely delete symbols that are not used throughout the project with the Safe Delete refactoring

Rename packages

Package rename and corresponding updates of all imports is now supported

Rename Package

Integration with Java’s Move refactoring

When performing a Move refactoring of Java code, it now updates the corresponding usages in Kotlin code.


This release also brings a series of Intentions to IntelliJ IDEA, including:

Replacing Elvis operator with If conditional

The safe access operator, or elvis operator, can be now replaced with a more explicit if conditional when required just by simply using intentions.


 Infix calls to dot qualified calls

Infix calls can be converted to dot qualified calls


Convert to expression body

Ability to convert a function with a simple return statement to an expression


Add and remove braces from simple variable names in string templates

When we have variable names in string templates, we can easily add or remove curly braces


In addition to the above, there’s also

  • Support for IntelliJ IDEA 13.1 and Android Studio
  • Performance improvements through lazy analysis, leading to better interop speed with Java also.
  • Improvements in the Java2Kotlin Converter, leading to cleaner code and including better copy/paste behaviour.
  • Improvements in Code Formatter

Other improvements

In addition, there are some other bug fixes and features

  • Improved Control-Flow Analysis resulting in fixing some existing bugs.
  • More bootstrapping. We’re using more and more Kotlin in Kotlin.
  • Some more improvements to the Kotlin standard library.

You can find the Compiler and Plugin on our release page on GitHub.
If you’re using IntelliJ IDEA, you can download the latest plugin from our repository or update it directly via Plugins in IntelliJ IDEA. Kotlin M7 requires IntelliJ IDEA 13.1.

This entry was posted in Releases and tagged . Bookmark the permalink.

21 Responses to M7 Release Available

  1. Sergey says:

    Don’t you think that ability to inline is too low level feature for your language? Is it difficult for compiler to decide which methods to inline without help of programmer?

    • It’s traditional to think about inlining as a mere optimization, but this dates back to the times when software was shipped as one huge binary file.

      Why we think inline should be a language feature:
      1. Other language features (to be implemented soon) depend on it. Namely, non-local returns and type-dependent functions. Basically, inline functions are very restricted macros, and this is definitely a language feature.
      2. Due to dynamic linking and binary compatibility issues it can not be up to the compiler whether to inline something or not on the JVM: if bodies of inline functions change, all dependent code should be recompiled, i.e. it’s the library author’s liability to preserve functionality, so such functions must be explicitly marked.

  2. Denis says:

    Thanks! That’s great!

  3. Gaetan Zoritchak says:

    Really nice job!

    The IntelliJ IDEA Enhancements are really cool but please could you take in consideration http://youtrack.jetbrains.com/issue/KT-2428.

    The multi language support of idea is one of its major features. The lack of the multi language feature is a stumbling block for the adoption of kotlin in “real” projects.

    I use kotlin in production but loosing sql, hql, … support is the real pain in my neck :


    • Thanks. We’ll look into it, but I can’t promise much about the timing.

      • Gaetan Zoritchak says:

        Thanks a lot.

        We are many to see kotlin as a very good language. I imagine how difficult it is to prioritize issues beetween the core language features and IDE’s ones.

  4. Guangyu HE says:

    Great work. WE have adopted it in the production enviroment.

  5. Mohammad Shamsi says:

    Great Work!.

    I wish to see following enhancements in Class Constructors, before Kotlin hits production:
    – Secondary constructors.
    – Having the primary constructor in class header as an option, NOT as a sole, mandatory option.

  6. Matt Gile says:

    We have been using kotlin in production now for about a year. It is mixed with Java (files side by side). Kotlin really shines at adapting an API to be more express, and concise. Using Extension Function, Extension Properties, Operator Overloading, and Functional Parameters you can create very rich, declarative API’s with only a few lines of code.

    What JVM does M7 Target? How far back, JVM wise, can I go? 1.5? 1.6?

  7. Jan Kotek says:

    Congratulations on new release. I work on Redis server written in Kotlin. I also use Kotlin heavily for testing on MapDB. I found it great.

  8. José María says:


    Is going to be possible to have a Design by Contract mechanism for Kotlin? Maybe could Kotlin be the first JVM language to have DbC support?

    Thanks in advance, best regards

    • Hadi Hariri says:

      No plans in the language itself. But this is something you could accomplish somewhat with annotations and tooling.

  9. Rusi Filipov says:

    +1 for DbC as a language feature. Something like Code Contracts in C#, it is awesome!

    For instance you declare postconditions programmatically (and type-safe) in the beginning of the method, but they are checked at the end. You declare a contract for an interface and all implementations are checked at runtime…

    • David Kerr says:

      +1 for DbC. I’ve only just discovered kotlin because of a search for a null safe language. Having DbC would really be fantastic. Allison based extensions just don’t cut the mustard in terms of inheritance, access to ‘old’ values, etc.

      Kotlin looks cool so far!

  10. Zoltán Tóth says:

    I find the inline function feature wierd.

    It bounds the inlining of the function with the inlining of its function parameters? Why this restriction? Why not separately deciding for each function parameter?

    Why the decision about whether to inline a function parameter is based on that if it is given as lambda or by name? If I give a name to my function should not alter run-time performance.

    • You can decide on each parameter separately, of course: while the default is to inline all parameters, you can annotate a parameter with [noinline], and override the default.

      Regarding names: the reason is purely technical: many names cannot be resolved to a value at compile time, so they can’t be inlined.

Comments are closed.