Kotlin logo

The Kotlin Blog

Kotlin Programming Language by JetBrains

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.

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

  1. Historia de Kotlin | Koatlin says:

    June 27, 2017

    […] 27 de Junio de 2017 se libero el primer build de Kotlin 1.2, la version M1 que contenia modificaciones en la sintaxis […]

  2. Mohammad says:

    June 27, 2017

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

    • 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.

  3. 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?

    • 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.

  4. Nik says:

    June 28, 2017

    So, no bitwise operators in 1.2 🙁

  5. 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?

    • 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.

  6. eugene says:

    June 28, 2017

    ternary operator?

    • - says:

      June 28, 2017

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

      • c says:

        June 30, 2017

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

    • Dmitry Jemerov says:

      June 29, 2017

      Not on the roadmap for 1.2.

      • 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.

  7. 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.

    • Suresh says:

      July 1, 2017

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

    • 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.

  8. 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”)

    • 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.

    • Dmitry Jemerov says:

      July 3, 2017

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

    • 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

    • 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.

    • 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.

      • 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

    • 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}”

  9. 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”.

    • 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.

  10. 以Java、Kotlin和Scala编写基本Spring Web应用的比较 - 莹莹之色 says:

    July 17, 2017

    […] Kotlin 1.2中得到修复 […]

  11. 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