Early Access Program Releases

Early access program for Kotlin 1.2 has been started

We’re excited to announce the start of the early access program for Kotlin 1.2: today its first milestone release 1.2-M1 is out.

This release enables by default new language features that were previously available in 1.1.x releases under experimental 1.2 language version setting. Also in the standard library you can preview the new API.

The complete though not so big list of changes in this release can be found in the changelog.

Language feature: array literals in annotations

The single notable language feature proposed in this milestone is array literals, whose usages are constrained to annotation arguments.

Earlier one had to write something like following to specify an array of values:

@CacheConfig(cacheNames = arrayOf("books", "default"))
public class BookRepositoryImpl {
    // ....

In Kotlin 1.2 a literal can be used instead of the arrayOf function:

@CacheConfig(cacheNames = ["books", "default"])
public class BookRepositoryImpl {
    // ....

An IDE inspection will propose you to use the new syntax of collection literals where appropriate.

Inline function with optional functional parameters

Up until now it was impossible to declare an inline higher order function with an optional functional parameter like the following:

inline fun <E> List<E>.printItems(transform: (E) -> String = { it.toString() })

One had to either make the function itself non-inline or mark the functional parameter as noinline. In either case that defeated the purpose of functional parameter inlining.

Now this case is fully supported.

Standard Library API

This release features two KEEPs (Kotlin Evolution and Enhancement Proposals) regarding the standard library API.

The first is KEEP-49 introducing additional operations and conversion extensions for BigInteger and BigDecimal types, for which we’d like to thank Daniil Vodopian.

The second one is KEEP-11 which covers a number of functions related to partitioning collections and sequences:

  • chunked(size: Int) extension function partitions a collection into blocks of the given size;
  • windowed(size: Int, step: Int) takes a window of the given size and moves it along the collection with the given step returning the sublists of elements falling into each window;
  • pairwise() extension returns all subsequent pairs in a collection.

Please try these extensions if you’re interested and tell us, whether they fit your use cases.

There are some other enhancements, such as fill() and shuffle() extensions for MutableList as well as shuffled() for List, also Regex class became serializable.


Earlier in 1.1.2 release we have introduced the opt-in JS typed arrays support. When enabled it translates Kotlin primitive arrays, such as IntArray, DoubleArray etc, into JavaScript typed arrays. Now the opt-in is no longer required as this support is enabled by default.

Pre-release notes

Note that the backward compatibility guarantees do not cover pre-release versions: the features and API can change in the subsequent releases. When we reach final RC, all binaries produced by pre-release versions will be outlawed by the compiler: you’ll be required to recompile everything that was compiled by 1.2‑Mx.
However all the code compiled by 1.1.x and earlier releases is perfectly fine without recompilation.

In this release you won’t be able to compile against the old runtime if you’re authoring inline suspend functions.

How to Try It

In Maven/Gradle: Add http://dl.bintray.com/kotlin/kotlin-eap-1.2 as a repository for the build script and your projects; use 1.2-M1 as the version number for the compiler plugin and the standard library.

In IntelliJ IDEA: Go to Tools → Kotlin → Configure Kotlin Plugin Updates, then select “Early Access Preview 1.2” in the Update channel drop-down list, then press Check for updates.

The command-line compiler can be downloaded from the Github release page.

On try.kotlinlang.org: Use the drop-down list at the bottom-right corner to change the compiler version to 1.2‑M1.

Comments below can no longer be edited.

30 Responses to Early access program for Kotlin 1.2 has been started

  1. Avatar

    Mohammad says:

    June 27, 2017

    Collection literals, are limited to annotations?
    Is this the final goal or the limitation is only in M1?

    • Avatar

      Andrey Breslav says:

      June 28, 2017

      This is an important use case. We haven’t finalised the design yet, so can’t say what the final plan for 1.2 is.

  2. Avatar

    Phantom says:

    June 28, 2017

    Are Coroutines available by default in 1.2, or like now that i have to add extra dependencies for that?

    • Avatar

      Ilya Gorbunov says:

      June 28, 2017

      Neither the status of coroutines, nor the need to depend on kotlinx.coroutines library with the advanced coroutine API have not been changed in this milestone.
      Further milestones might change this situation.

  3. Avatar

    Nik says:

    June 28, 2017

    So, no bitwise operators in 1.2 🙁

  4. Avatar

    Diego Gomez Olvera says:

    June 28, 2017

    Is there any change regarding the usage of FindBugs? https://discuss.kotlinlang.org/t/should-we-be-reporting-findbugs-issues/2105/2 If not, is it planned?

    • Avatar

      Dmitry Jemerov says:

      June 29, 2017

      At this time we don’t plan to release the new JVM backend in the 1.2 timeframe. We do invest effort into local improvements of the generated bytecode with our current backend implementation, so it would help if you could file issues regarding your FindBugs problems – we’ll look into them.

  5. Avatar

    eugene says:

    June 28, 2017

    ternary operator?

    • Avatar

      - says:

      June 28, 2017

      I like the if-else better.
      Any reason to favor ternary over if-else?

      • Avatar

        c says:

        June 30, 2017

        reads much better. at conventional exchange rates, a word is worth only a thousandth of a symbol.

    • Avatar

      Dmitry Jemerov says:

      June 29, 2017

      Not on the roadmap for 1.2.

      • Avatar

        Robert Hencke says:

        July 14, 2017

        The current form (having if/else as both expression and statement) is beautifully consistent and succinct enough for every use I’ve found. Thank you.

  6. Avatar

    diegomontoya says:

    June 29, 2017

    Is defer {} on the discussion or future roadmap? We find this a life safer when it comes to golang which reduces the number of bugs in multiple conditional return code that forgot to to properly release resources.

    • Avatar

      Suresh says:

      July 1, 2017

      Just curious, what defer solves better than finally {} ?

    • Avatar

      Robert Hencke says:

      July 14, 2017

      The use{} extension method on Closeable largely covers the scope of what defer does, albeit adding block scope when doing so.

  7. Avatar

    findev says:

    June 29, 2017

    Please include BigDecimal and BigInteger literals.
    A good format would be a dollar prefix.

    $100.23 is the literal for new BigDecimal(“100.23”)
    $5000 is the literal for new BigInteger(“5000”)

    • Avatar

      py says:

      July 3, 2017

      Though this is a interesting point, why dollar prefix? not everything is about money and a dollar sign may confuse people.

    • Avatar

      Dmitry Jemerov says:

      July 3, 2017

      Additional numeric literal formats are not on the roadmap for 1.2.

    • Avatar

      DonRobo says:

      July 6, 2017

      I think the extension function route is much nicer. It allows developers to use whatever number type they want without polluting the language with literals for many library classes.

      $5000 is not much better than 5000.bd in my opinion. It’s also closer to the traditional type modifier 1000L or 5.0f

    • Avatar

      Jakub Gwozdz says:

      July 16, 2017

      I’d love that addition. Not sure if a dollar sign is the best prefix, but the whole idea of having literals for BigInteger/BigDecimals is great.

    • Avatar

      alanfo says:

      July 19, 2017

      In due course I’d also like to see literals introduced for the ‘Big’ types though my suggestion would be to use a ‘g’ suffix (think ‘g’ for gigantic) which would be more consistent with the present system. So 100g would be a BigInteger and 100.0g would be a BigDecimal.

      It would also be nice to have literals for the Byte and Short types so that, in many cases, you could declare and initialise variables of these types without having to specify the type or having to use the long-winded toByte() or toShort() functions applied to an Int literal. For Short you could use an ‘s’ suffix though unfortunately you couldn’t use ‘b’ for Byte because of possible confusion with hexadecimal integers. A reasonable compromise would to use the second letter ‘y’ instead which is what F# does.

      • Avatar

        Tapac says:

        July 27, 2017

        In addition to my previous comment, why not use that in your code:
        val Int.g : BigInteger get() = BigInteger.valueOf(this.toLong())
        val Double.g : BigDecimal get() = BigDecimal.valueOf(this)
        123.g + 12345.g

    • Avatar

      Tapac says:

      July 27, 2017

      Why not to create your own extentions, like
      operator fun Int.not() : BigInteger = BigInteger.valueOf(this.toLong())
      operator fun Double.not() : BigDecimal = BigDecimal.valueOf(this)
      and use it as !112 + !12345 ?

      I guess that $ already used in string templates and it will confuse when you will try to write something like “${$1.111}”

  8. Avatar

    Salomon BRYS says:

    July 5, 2017

    Inline function with optional functional parameters do not seem to work in Android Studio.

    With the plugin 1.2-M1-release-Studio3.0-1 and using kotlin 1.2-M1, the following code is highlighted as an error :

    inline fun <reified T> Context.intent(block: Intent.() -> Unit = {}) = Intent(this, T::class.java).apply(block)

    The error is “Construction is not yet supported in inline functions”.

    • Avatar

      Ilya Gorbunov says:

      July 14, 2017

      Is this code compiled fine with gradle? If not, please ensure you’re using kotlin-gradle-plugin of version 1.2-M1 in the classpath of buildscript.

  9. Avatar

    Mikhail Fursov says:

    July 18, 2017

    Hi guys,

    Kotlin is designed to be very safe language, but for some reason it includes very error prone feature: position based declaration destructuring.

    Other languages (like ES6/TypeScript) use property name based destructuring and are safe to properties reordering, but Kotlin is not. Kotlin hides property reordering. (please correct me if I’m wrong)

    What was the reason to select position based destructuring over name based one?
    Is there any chance to get rid of it in one of the future releases?

Discover more