The Roadmap to Kotlin 1.1

| by Sergio De Simone Follow 7 Followers on Jun 09, 2016. Estimated reading time: 2 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

Kotlin development is heading towards version 1.1; Kotlin lead language designer Andrey Breslav explained the roadmap to JetBrains’ JVM language new version, which will include major new language features.

Kotlin 1.1 will provides a number of new language features:

  • type aliases are meant to be an abbreviation mechanisms for longer types declarations, such as function signatures; type aliases will not introduce new types and can be used interchangeably with the original definition.

  • bound method references will be extended to support taking a reference to a member of an object. In this way, you can take a reference to the equals method of a String object and assign it to a predicate to use it later: val p: Predicate<String> = “foo”::equals. Kotlin 1.0.x already supports this for types.

  • delegated properties will be allowed at the top level, in a class, or in a function:

    fun foo() {
      val lazyBar by lazy { ... }
      while (...) {
        if (...) {

    Delegated properties are a mechanism to implement once and for all certain kinds of properties, such as lazy, observable, and map-stored properties, so they do not need be implemented each time.

  • data classes will support inheritance, thus making it possible to derive a data class from another. Data classes are classes that just hold data, and for which Kotlin automatically generates accessors, equals, hashCode, and other common methods. This will also make it possible to extend a data class from within a sealed class:

    sealed class C() {
      data class Example(...) : C()
  • destructuring will allow to assign composed names to arguments of lambdas, such as in the following example, where the argument to forEach, a pair, is destructured in its two components:

    myMap.forEach {
      (k, v) ->
        println(“$k => $v”)
  • coroutines will provide the backbone for Kotlin async behaviour. According to Breslav, coroutines are more general than the async/await model introduced in C# 5. Kotlin will also provide async/await, but built on top of coroutines, not as primitives:

    fun loadImage(url: URL) = async {
      val bytes = await(loadBytes(url))

On the tooling front, Kotlin 1.1 will include direct support for Java 8/9 features, such as default method generation. Additionally, the JavaScript backend will be brought in line with the actual set of language features.

Kotlin development is driven by the Kotlin Evolution and Enhancement Process (KEEP), based on a GitHub repository where all planned use cases are described.

Kotlin 1.1 will be both source and binary compatible with previous versions, meaning that new versions of Kotlin compiler will not break compatibility with older source code and binaries.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Illegible code by Javier Paniza

Features such as type aliases and bound method references made the code more illegible. New languages are obsessed to be very succint (you want to save the poor programmer to type many letters), not to be as Java (verbose). This is an error because in real life we expend most of our time reading code, not writing, and many time reading code written by others, then type aliases and bound method references are very inconvenient, then a verbose language is better.

Re: Illegible code by Luke deGruchy

Not all new languages are excessively terse.

Re: Illegible code by William Smith

+1 - I think as an industry we obsess about “developer productivity” but it’s totally the wrong thing to think about. If your code is successful it will be in production for years, and need maintaining. Java is great for this because the code is incredibly easy to follow - I don’t know another language like this. Even c#, which is at root the same language, doesn’t manage it due to the overwhelming Scala like number of features.

Actually I’m puzzled by Kotlin generally. As with Red Hat’s Ceylon I just can’t see what it’s for. I guess when Java stagnated, during the dying days of Sun, it was tempting to think we need a new JVM language - particularly if you didn’t like Scala. But what is the UVP for Kotlin? Ok it has a more terse syntax than Java (which I consider a weakness not a strength) but why would I/should I invest time learning it?

Re: Illegible code by Luke deGruchy

Newer languages have newer features according to more modern design principals instead of those from 20 years ago.

Re: Illegible code by Javier Paniza

Hi Luke, "newer" is not synonymous of "better". Only from time to time a newer thing is also better. However, for a programmer "newer" is always better, because they are always looking for intelectual challenges, not matter if they are not practical, no matter if they ignore the user.

Re: Illegible code by Jan Kovar

Illegible code can be written in any language whether it is Java or Kotlin. However the code written in Kotlin will be shorter and therefore easier to understand and refactor than the similar piece of code written in Java.

Re: Illegible code by Sergio De Simone

While I understand there is a risk that features such as type aliases could be used wrongly, it is also true that there are cases where they could help making code more readable. Specifically in the case that is mentioned with type aliases, i.e., function declarations: you could use a symbolic name that expresses the intent of your function (e.g., a callback to a network request) instead of just describing its parameters. So, I think your mileage may vary a lot depending on how you use that feature, as well as on how clever your naming conventions are.

Re: Illegible code by Javier Paniza

will be shorter and therefore easier to understand

Ha, ha, ha...

Try to read a chunk of COBOL code then try to read a chunk of RPG code. Which is more verbose? Which is easier to understanda?

Re: Illegible code by Chandan T P

+1. Language features that make code concise at the cost of readability is not a good thing.

Re: Illegible code by mirc mircus


Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you