Kotlin 1.1 Release Candidate is Here

As of today, Kotlin 1.1 has finally reached the release candidate stage. This means that most of our development work is done, we’re happy with the results, and we’ll soon publish them as a final Kotlin 1.1 release. We’ve done a lot of testing for this release internally, but the real world is always more varied than any test environment, so we need your help. Please try this build, and let us know about your experience!

11RC-01

The only new feature in the release candidate is the takeUnless function – a counterpart of takeIf (added earlier in 1.1) but with an inverted condition. As for bugfixes, there’s much more, and the changelog gives you a complete list. Among other things, we’ve fixed several performance problems in the IDE – both long-standing sore points and recent regressions.

Migration Notes

As we noted earlier, all binaries produced by pre-release versions are outlawed by the compiler: you’re now required to recompile everything that was compiled by 1.1‑M0x and Beta’s. All the code from 1.0.x is, of course, perfectly fine without recompilation.

Up until now, you could run the Kotlin compiler under any version of Java starting with Java 6, but this is about to change – starting with one of the first 1.1.x updates, the compiler will only run under Java 8 or 9. To prepare you for the migration, the compiler now emits a warning if you run it under Java 6 or 7. Note that this only affects the build environment; the compiled code is still compatible with Java 6 by default, and we have no plans to remove the support for that.

The .javaClass extension property is now deprecated. As a replacement, please use ::class.java. The IDE offers a quickfix to update usages, both individually and across the entire project.

To reduce the size of the JavaScript standard library, we’ve deprecated a lot of helper functions in the kotlin.dom and kotlin.dom.build packages, and we’re going to remove them in a future update.

How to try it

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

In Eclipse: install the plugin with the following update site
https://dl.bintray.com/jetbrains/kotlin/eclipse-plugin/0.8.0

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

On try.kotlinlang.org.

Let’s Kotlin!

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

21 Responses to Kotlin 1.1 Release Candidate is Here

  1. Mike says:

    ‘As a replacement, please ::class.java.’
    Did you mean ‘please use’, or, maybe, ‘please write’?

  2. Pingback: Kotlin 1.1 RC is Here | Ace Infoway

  3. Maciej Górski says:

    Please change to “the compiler will only run under JDK 8 or 9”. It causes fear among developers when it says Java there :)

  4. Vitalii Kravchenko says:

    Also don’t forget to update this dependency, if you used coroutines in 1.1-beta:
    https://bintray.com/kotlin/kotlin-eap-1.1/kotlinx.coroutines

  5. Pingback: Kotlin 1.1 RC 版发布,即将发布正式版 | News Pod

  6. Alex Berry says:

    This is great news. I’m doing a one off project for work next week during a hack-a-thon and I plan on using this release. I haven’t written any practical code using coroutines so I’m looking forward to it.

  7. hhhxxjj says:

    Congratulations. Looking forward to Kotlin 1.1

  8. kotlin-user says:

    do kotlink run on java prifile compact1 ?

    http://www.oracle.com/technetwork/java/embedded/resources/tech/compact-profiles-overview-2157132.html

    do kotlin support java modularity from java 9 ?

  9. Martin Vysny says:

    Great news! Looking forward for 1.1 final :)

    Please, what’s the status of Gradle integration? Will the IDE plugin work out-of-the-box with Kotlin Gradle scripts when 1.1 is released? Also, when will the Kotlin support be mainlined into official Gradle? Currently one needs to use custom Gradle builds if I’m not mistaken.

    Thanks!

  10. Pingback: Выпущен релиз-кандидат Kotlin 1.1 – Русский Эпик

  11. Max says:

    Is Kotlin coroutine support always going to be vended as separate kotlinx-coroutines-* modules, or is it going to be rolled into the core release at some point?

  12. Pingback: JVM-Sprache Kotlin: Zweite Beta-Version von Kotlin 1.1 erschienen [Update] - JAXenter

  13. Victor says:

    Kotlin, I really like it

  14. Chris Hatton says:

    Congratulations on the release, I am very excited about Kotlin and have just successfully nominated it as our chosen language for Android Development at work.

    One problem I have to point out with your release process is: I am earnestly trying to learn about the new co-routines feature and frankly I am totally lost with the simplest use-case. This is because I cannot see a definitive API published for 1.1, or an official comprehensive guide to the coroutines feature. All I can see it an incomplete example in the release notes and a whole load of blog-posts which all relate to the 1.1-M0x releases whose API has since changed.

    So on the whole, co-routines: a feature I’m completely sold on and completely unable to use because there is no reliable information on it.

    • Sorry, the final docs are under way. Please refer to the KEEP document and this repo for now: https://github.com/Kotlin/kotlinx.coroutines

    • Please, please Kotlin team release an end-to-end example of how coroutines would work IN PRACTICE. UI code calling into service layer (what’s the abstraction there), service layer calling into a networking library (Retrofit), JSON getting parsed into model (on BG thread) and model/results propagating up to the presentation layer for subsequent hydration. WITH handling of errors (how do these map to throwing in Kotlin?). Do failed continuations properly work across async calls as they do in C#? ie: throw clause in code that awaits gets properly executed as a continuation of the failed continuation?

      All this is NEEDED for us to adopt on projects and give you feedback.

      DON’T leave the documentation for the “last step of the release” for something you’re trying to foster feedback for upfront. Makes no sense. It’s a recipe for releasing the ‘final’ 1.1 and then realizing right after that you got it all wrong. We don’t to see you getting there – and while you’ve put so many betas out and took time to prep the community you guys missed the most crucial step –– guidance to people ADOPTING this feature so that people can actually do prototypes / POCs and test things out with real projects/libraries to give you quality feedback. #communityfeedbackfail #constructivehardlove

Leave a Reply

Your email address will not be published. Required fields are marked *