Kotlin 1.1 Beta Is Here!

Posted on by Andrey Breslav

Congratulations! Today Kotlin 1.1 has reached Beta, and this means that

  • it’s time to try it out,
  • there’s still time to give us your feedback (and we really need it!),
  • the release is coming fairly soon.

Kotlin 1.1 Beta

We’ve seen a lot of interest in Kotlin over the past year, and would like to thank all our users, contributors and supporters. Special thanks to early adopters of new features for their bravery and feedback to our EAP builds!

An overview of what is coming in Kotlin 1.1

The biggest news of Kotlin 1.1 are

  • full support of compilation to JavaScript, and
  • Coroutines on the JVM, Android and JavaScript.

We’ll give some more details about these below, but they are not the only exciting news of 1.1. Many more language improvements and new features are coming (more details are available on our What’s new page):

Deprecation

We deprecate the unfortunate name mod that we used for the % operator, and replace it with rem, which is semantically correct and agrees with existing libraries such as java.math.BigInteger. Deprecation warnings and the tooling will guide you through the migration process.

JavaScript

It’s simple: the full Kotlin language can be now compiled to JavaScript. It doesn’t mean that we have ported all of the JDK into the browser: the language and its Standard Library are not coupled with JDK, but you can use Kotlin strings, collections, sequences, arrays and other core APIs on JS as well as JVM/Android.

Numerous popular JS libraries will be available through typed headers (converted from DefinitelyTyped). We support all popular runtime module systems for JavaScript as well as webpack and other important tools.

We’ll dedicate a lot of effort in Kotlin 1.2 and beyond to making the JavaScript tooling smooth and helpful. Our goal is to enable pleasant full-stack development with Kotlin.

Coroutines

Honestly, it’s hard to over-emphasize coroutines. The future has come, and we are stuck with it: we need non-blocking asynchronous APIs to keep up with the loads of data we are processing. We’ve been through callback hell and conquered it, but we deserve better. We want to simply write the code following its natural sequential logic, and let the compiler figure the asynchrony out for us. This is what coroutines are about: async/await, generate/yield, non-blocking IO, Rx and much more brought under the single unified paradigm of a suspending function. Such a function (or lambda) represents a computation that can be suspended (without blocking any threads) and resumed later.

future {
    val original = asyncLoadImage("...original...") // creates a Future
    val overlay = asyncLoadImage("...overlay...") // creates a Future
    ...
    // suspend while awaiting the loading of the images
    // then run {{EJS0}} when they are both loaded
    return applyOverlay(original.await(), overlay.await())
}

The main benefit of coroutines is their flexibility:

  • The language part is minimal
  • Everything can be written as a library
  • Libraries are in total control of all aspects of suspending and resuming computations: threads, exceptions and other aspects of computation are entirely customizable.

We have written a set of libraries for interesting common use cases: kotlinx.coroutines

Read more about coroutines here.

An important note. With all the benefits that they bring, Kotlin coroutines are a fairly new design that needs extensive battle-testing before we can be sure it’s 100% right and complete. This is why we will release it under an “experimental” opt-in flag. We do not expect the language rules to change, but APIs may require some adjustments in Kotlin 1.2.

  • Command line: -Xcoroutines=enabled
  • Gradle: kotlin.coroutines=enable in gradle.properties or local.properties
  • Maven: <configuration> <args> <arg>-Xcoroutines=enable</arg> </args> </configuration>
  • IDE: Use a quick-fix (Alt+Enter) or modify the facet options (Project Structure -> Modules -> Your Module -> Compiler -> Coroutines (experimental))

Standard Library, Tooling and Frameworks

Kotlin’s Standard Library is getting updated with many useful utilities and extensions including those specific for JDK 7 and 8.

Our collaboration with Gradle has resulted in gradle-script-kotlin which means that you can now write type-safe build scripts for Gradle, using Kotlin scripting.

We now support JSR 223, which is utilized by the Spring Framework along with type-safe DSLs and other things.

How to Try It

As with other pre-release versions, we give no backward compatibility guarantees for Kotlin 1.1‑Beta. Moreover, 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.1‑M0x and Beta (all the code from 1.0.x is perfectly fine without recompilation).

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

In IntelliJ IDEA: Go to Tools → Kotlin → Configure Kotlin Plugin Updates, then select “Early Access Preview 1.1” 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.1‑Beta.

Let’s Kotlin!

Comments below can no longer be edited.

56 Responses to Kotlin 1.1 Beta Is Here!

  1. Michel says:

    January 19, 2017

    Does the book “Kotlin in action” will be updated with the changes in 1.1 before it is released ?

    It would be great !

    • Dmitry Jemerov says:

      January 21, 2017

      Unfortunately not. The book mentions some of the changes in 1.1, but the schedule of the book release has not allowed us to provide complete coverage of the new features. If there’s ever a second edition of the book, it will of course cover later Kotlin versions.

  2. Martin Eden says:

    January 19, 2017

    Hi. I have a Gradle-based IntelliJ IDEA project. I added Kotlin 1.1 as a dependency in gradle.build, and also updated IDEA to use the “Early Access Preview 1.1”, as per the instructions above. IDEA downloaded Kotlin 1.1 beta and restarted. Gradle spent some time indexing and fetching new bits and bobs. So far, so good.

    I am now getting this compile error in IDEA: “The feature is only available since Kotlin 1.1: bound callable references”. So where previously I just had a syntax error, it now knows my use of bound callable references is a (futuristic) language feature. But it’s still a compile error.

    Presumably I need to enable 1.1 functionality somewhere else in IDEA. Any suggestions?

    Thanks 🙂

    • Martin Eden says:

      January 19, 2017

      Also, in the Maven Repository Index window in IDEA the new repository (added via gradle) ” http://dl.bintray.com/kotlin/kotlin-eap-1.1” is listed. However, when I ask IDAE to fetch indexes from the repository it results in an error: “Resource nexus-maven-repository-index.properties does not exist”.

    • Viktoria says:

      January 19, 2017

      Please be sure that in the Project Structure / Facets / Kotlin “language version” and “api version” are set into 1.1. Check all facets in your project.

    • Tim van der Leeuw says:

      January 19, 2017

      Do you perhaps need to refresh the Gradle project so that IntelliJ will pick up the changed dependencies?

      • Martin Eden says:

        January 19, 2017

        You know, I could have sworn I tried that several times. But that seems to have worked! Thank you for the suggestion 🙂

  3. Nik says:

    January 19, 2017

    does beta contain all latest kapt3 fixes?

    • Mikhail Glukhikh says:

      January 19, 2017

      Yes, at least it should

  4. Anton says:

    January 19, 2017

    Nice!

    But why the long “typealias” instead of just “type” or “alias”?

    • Andrey Breslav says:

      January 19, 2017

      “type” is too often used in other contexts to make it a keyword, proved very annoying when we initially reserved it. “Alias” looks a bit too generic

      • eugene says:

        January 19, 2017

        would it be possible to write:
        Action as (T) -> Unit
        instead of:
        typealias Action = (T) -> Unit

        • Andrey Breslav says:

          January 19, 2017

          Looks like a proposal of new syntax. No, we are not planning to support this syntax yet. 🙂

          • eugene says:

            January 19, 2017

            i simply remembered aliases in sql:
            SELECT column_name AS alias_name
            FROM table_name;
            and i associated that sql’s as with kotlin’s as:
            findViewById(R.id.button) as Button?

    • K. S says:

      January 20, 2017

      +1
      typealias is too long. “alias” would have been a better name.

  5. Peter says:

    January 19, 2017

    Speaking of try.kotlinlang.org, any plans to release its source code? It would be really nice to be able to embed a simple runnable Kotlin “fiddle” with autocomplete support into blogposts and other websites.

    • Roman Belov says:

      January 19, 2017

      Hi Peter!
      The current plan is to provide embedding option on the try.kotlinlang.org

  6. Michel says:

    January 19, 2017

    Is there another way to download the IDEA Kotlin plugin ? Because when using “Tools → Kotlin → Configure Kotlin Plugin Updates” then “Early Access Preview 1.1” and click “Check for update now” it keeps saying that i have the lastest version of the plugin (1.1.0-dev-6158) installed.

    (there are no errors in the IDEA logs)

    • Viktoria says:

      January 19, 2017

      Hi,
      You need to uninstall the existing Kotlin plugin (1.1.0-dev-6158), then please check Settings / Plugins / Browse repositories… / Manage repositories… and remove path where you have installed the dev version from.
      After that repeat installation of beta using “Tools / Kotlin / Configure Kotlin Plugin / Updates Early Access Preview 1.1 / Check for update now”

      • Michel says:

        January 19, 2017

        Oh yes, i had a custom path to a dev jetbrains plugins repository. I forgot that. It works now!

        Thank you !

  7. Martin says:

    January 20, 2017

    Thanks for the new version!

    Small feedback:

    1) mention that for Maven one needs to add the also as to be able to fetch kotlin-maven-plugin

    2) I’ve tried to build my project but it fails with:

     java.lang.NoClassDefFoundError: Could not initialize class kotlin.reflect.jvm.internal.impl.platform.JavaToKotlinClassMap
    

    Any hints what could be the problem ?
    I cannot share my code :-/

    • Martin says:

      January 20, 2017

      I see that 1) didn’t render properly. Will try again:
      1) mention that for Maven one needs to add the <repository> also as <pluginRepository> to be able to fetch kotlin-maven-plugin

    • Alexander Udalov says:

      January 20, 2017

      Re NoClassDefFoundError: it looks like a misconfiguration issue, please make sure you have an explicit dependency on kotlin-reflect of version 1.1.0-beta-17. If that’s the case and the error is still happening, please report an issue with the full stack trace at kotl.in/issue. Thanks!

  8. Jire says:

    January 20, 2017

    This is awesome news!

    Are any examples for using JSR 223 with Kotlin? I’ve tried to use it and it still seems to not resolve dependencies on the classpath, which I think is a big missing feature. There was also some talk about scripts just generating object classes with an operator invoke function, so that a script called “example.kts” would be able to be easily invoked with “example()”. Is this something still being considered?

    • Ilya Chernikov says:

      January 20, 2017

      A sample ready-made engine with basic tests is here. In this version it tries to use the classpath of the executing environment, and should be able to resolve classes from there. But you can fine-tune it by implementing your own factory like this and use a desired classpath in place of templateClasspath parameter of the KotlinJsr223JvmDaemonCompileScriptEngine constructor.

      Another example of JSR 223 usage in the Spring Framework 5.0 code. You can read more about it in the announcement.

      There are a lot of discussions about JSR 223 and scripting in general going on in the #scripting channel on the public slack.

  9. Kotlin 1.1 Beta 发布 | 客家网络 says:

    January 20, 2017

    […] 发布主页 […]

  10. Kotlin 1.1 Beta 发布,正式版还会远吗? | News Pod says:

    January 20, 2017

    […] 发布主页 […]

  11. JVM-Sprache Kotlin: Kotlin 1.1 Beta erschienen [Update] - JAXenter says:

    January 20, 2017

    […] unterstützt. Mehr Informationen zum Release finden Sie in dem von JetBrains veröffentlichten Blogpost. Es gibt übrigens einen frischen Kotlin-Podcast, mit dem Sie immer auf dem neusten Stand […]

  12. Alexander Roman says:

    January 20, 2017

    Do you have plans developing Anko? Moreover, fixing Anko DSL Preview plugin for fresh Android Studio versions? Anko is an awesome tool, but missing preview makes it nearly impossible to use in production.

    • yanex says:

      January 20, 2017

      Yes, we have plans about Anko and its preview plugin, though for now we are focused on the upcoming Kotlin 1.1 release.
      Also, as Anko is an open source project, we are always open to external contributions.

      • Xavier Fernández says:

        January 22, 2017

        The DSL marker and co-routines will also be implemented in Anko as well?

        Thank you a lot 🙂

        • yanex says:

          January 30, 2017

          Yes, of course. Anko will be adopted in order to support DSL marker. The extra artifact for coroutines will also be provided in near future.

  13. Keyhan says:

    January 20, 2017

    Does the javascript support mean that it would be possible to write angular2 or react applications in Kotlin?

    • Andrey Breslav says:

      January 28, 2017

      We have positive experience using React with Kotlin, haven’t tried Angular yet.

      You can use any libraries and frameworks from Kotlin, and the better they can be typed (e.g. through TypeScript or WebIDL) the more convenient it will be, for what can’t be typed, you can always use the dynamic type.

  14. paulc says:

    January 22, 2017

    When will the javascript documentation be updated? Personally I will not take Kotlin serious for full stack development until the DefinitelyTyped support is documented and it works for angular2 and underscore.

    • Dmitry Jemerov says:

      January 23, 2017

      The JS documentation is being updated (we released a number of new tutorials and docs pages for 1.0.4, 1.0.5 and 1.0.6 releases) and will continue to be updated for the 1.1 release and after that. We definitely plan to provide documentation for the TypeScript definition converter and sample applications for popular JS frameworks.

  15. CSC14US says:

    January 23, 2017

    I’m concerned with feature creep that Kotlin is becoming too complicated for its own good. I was interested in it initially as an alternative to Java that’s not as complicated as Scala. Especially without learing resources such as an “effective Kotlin” series, how are developers intended to master this rapidly evolving tool?

    • Alex Berry says:

      January 24, 2017

      I’m not worried about feature creep just yet. Kotlin is still a new language and even though this post includes a large list of changes most of them are just small changes that don’t affect day to day coding much. Is it nice to have destructuring when you loop over a map? Yes. Is code that doesn’t take advantage of this feature bad or poorly written? No. If you read code that uses that feature and you didn’t know that specific feature existed can you still understand that code? Most likely. And I think most of those features fall under that category. From what I can see there’s really just one big new feature in release (full javascript compilation support is nice but that’s not really a new feature just a completed one).

  16. Piotr Pędziwiatr says:

    January 23, 2017

    what about parallel compilation? current non thread-safe compilator is a big issue for any bigger, multi-module, real-life project…

    • Andrey Breslav says:

      January 23, 2017

      We are looking into it

      • Piotr Pędziwiatr says:

        February 1, 2017

        can’t wait for the results 🙂

  17. Paweł Włodarczyk says:

    January 23, 2017

    It seems like this build also doesn’t generate interfaces with Java 8 ‘default’ keyword anymore even with ‘-jvm-target 1.8’. It was still doing so in a previous update. I’m also wondering wherever next release will be compiling lambdas with invokedynamic and LambdaMetaFactory. Without that feature using some DSLs cause to generate tons of anonymous classes right now 🙂

    • Andrey Breslav says:

      January 24, 2017

      On default methods: this features conflicts semantically with Kotlin inheritance by delegation, so we had to withdraw it for now.
      On lambdas: it’s on our roadmap, but not coming in 1.1

  18. Yuri Stiopin says:

    January 27, 2017

    Hey, I’m writing FRP framework using Kotlin JavaScript SDK, and it is very sad there is no reflect API on this sdk yet 🙁 Do you plan to implement it fully? If yes, it would be so cool!

    • Andrey Breslav says:

      January 28, 2017

      It’s not a trivial task, but we realize how useful it is and it’s on the table. Meanwhile, you can use the means of reflection available natively in JS

      • Yuri Stiopin says:

        January 29, 2017

        Very nice idea! I think I missed it somehow in my Kotlin rush

  19. How “Effective Java” may have influenced the design of Kotlin – Part 2 | Lukas Lechner says:

    January 28, 2017

    […] news: The recently announced Kotlin version 1.1 beta provides compiler plugin for making classes open by […]

  20. Marcel Bradea says:

    January 29, 2017

    Are futures / CompletableFutures usable in Kotlin on anything other than API level 24 (Nougat 7.0)?

    Alternatively is there any Kotlin couroutine support for the backported ‘streamsupport’ library (https://sourceforge.net/projects/streamsupport/) which backports CompletableFuture?

    Would be great to see these working together – so we can apply async to Android in practice 🙂

    • Roman Elizarov says:

      January 30, 2017

      CompletableFuture class is defined in Android API level 24. However, you don’t need to have futures to enjoy the power of coroutines. In fact, the support for futures is totally optional and even comes in a separate artifact kotlix-coroutines-jdk8. You need it only if you have a legacy futures-using code that you need to interoperate with. The core support for coroutines in kotlinx-coroutines-core provides a host of useful primitives to work with coroutines and it works on any Android or JDK6+.

      If your project heavily uses backported futures from streamsupport and you need to integrate them with coroutines, then you are welcome to copy-and-paste the code of kotlinx-coroutines-jdk8 module to adapt it to the implementation of the futures that you are using. It is just a single file: https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-jdk8/src/main/kotlin/kotlinx/coroutines/experimental/future/Future.kt

      • Marcel Bradea says:

        January 30, 2017

        Thank you for clarifying that Roman.

        I wanna give the team some honest feedback… we’ve been following all the great stuff you guys have been doing with async, but you guys totally need a full end-to-end blog/tutorial on how to integrate this on Android in a PRAGMATIC way (ie: not proof-of-concept, but production-grade, works in practice kinda way).

        What I mean is providing an end-to-end example of how to integrate from networking to biz layer to presentation. For example how does Kotlin integrate with Retrofit (prob the most popular networking lib on Droid right now), parse JSON, propagate networking errors/exceptions to upper levels, allow chain/parallel continuations up in the biz/presentation layers, and thread switch appropriately so that network results processing happens on BG and marshals back to UI for the rest?

        For some background, our team has a lot of familiarity with async/futures (we uses C#./.NET on the back-end and a Swift futures library along with Bolts on Android – ie: each toolset it’s best-of-breed approach)…. yet we find it prohibitively complex to figure out how to mix all this on Android/Kotlin 1.1 from just the blog posts you guys have been putting out.

        Right now a practical stack looks something like:
        – Retrofit (“com.squareup.retrofit2:retrofit”) – networking
        – Retrofit GSON (“com.squareup.retrofit2:converter-gson”) – JSON parsing
        – Bolts (“com.parse.bolts:bolts-tasks”) – continuations
        – Retrofit Bolts adapter (hand-rolled) – error handling ie: map Retrofit representation of errors to Bolts representation of errors

        What is the Kotlin async alternative?

        Give us a best-practice recommendation….. not a myriad of options (has always been Java’s biggest downfall). Take a stance. Provide us the way. If we’re going to re-architect our entire app stack for Kotlin 1.1 async today, how should it be done?

        • Andrey Breslav says:

          February 10, 2017

          There’s no comprehensive guide yet, we’ll roll out the docs and tutorials as they are ready. And it’s a bit early for best practices, although we’ll definitely publish as much of our vision about how coroutines are intended to be used as possible.

          Meanwhile you may benefit from looking at this repository: https://github.com/Kotlin/kotlinx.coroutines

  21. Cómo usar KotlinJS como sustituto de Javascript para desarrollo Web | Esther Claravalls says:

    January 30, 2017

    […] sigue creciendo, y gracias al lanzamiento de la beta de Kotlin 1.1 ya tenemos toda la potencia de la que ya disponíamos para la JVM ahora también en […]

  22. Cómo usar KotlinJS como sustituto de Javascript para desarrollo Web @soynadieorg – Soynadie Photo Press says:

    February 4, 2017

    […] sigue creciendo, y gracias al lanzamiento de la beta de Kotlin 1.1 ya tenemos toda la potencia de la que ya disponíamos para la JVM ahora también en nuestros […]

  23. Nick says:

    February 9, 2017

    I have IDEA 14.1.7 with Kotlin 1.0.4, when I try to select “Early Access Preview 1.1” in the Update channel drop-down list, I only see “Early Access Preview”, and it finds no updates. Is there something else I need to do to get the beta working?

    • Dmitry Jemerov says:

      February 10, 2017

      Yes. You need to upgrade to IntelliJ IDEA 2016.1 or newer.

  24. Cómo usar KotlinJS como sustituto de Javascript para desarrollo Web - TODO SOBRE LA WEBTODO SOBRE LA WEB says:

    February 14, 2017

    […] sigue creciendo, y gracias al lanzamiento de la beta de Kotlin 1.1 ya tenemos toda la potencia de la que ya disponíamos para la JVM ahora también en nuestros […]