Kotlin 1.2 Released: Sharing Code between Platforms

Members of our community have translated
this blog post into several languages:

Today we’re releasing Kotlin 1.2. This is a major new release and a big step on our road towards enabling the use of Kotlin across all components of a modern application.

In Kotlin 1.1, we officially released the JavaScript target, allowing you to compile Kotlin code to JS and to run it in your browser. In Kotlin 1.2, we’re adding the possibility to reuse code between the JVM and JavaScript. Now you can write the business logic of your application once, and reuse it across all tiers of your application – the backend, the browser frontend and the Android mobile app. We’re also working on libraries to help you reuse more of the code, such as a cross-platform serialization library.

Kotlin 1.2 is already bundled in IntelliJ IDEA 2017.3, which is being released this week. If you’re using Android Studio or an older version of IntelliJ IDEA, you can install the new version from the Tools | Kotlin | Configure Kotlin Plugin Updates dialog.

This release includes a lot of work done by external contributors, and we’d like to thank everyone who sent us feedback, reported issues, and especially those who submitted pull requests.

Multiplatform Projects

A multiplatform project allows you to build multiple tiers of your application – backend, frontend and Android app – from the same codebase. Such a project contains both common modules, which contain platform-independent code, as well as platform-specific modules, which contain code for a specific platform (JVM or JS) and can use platform-specific libraries. To call platform-specific code from a common module, you can specify expected declarations – declarations for which all platform-specific modules need to provide actual implementations.

For more information on the feature, please check out the documentation.

As mentioned previously, we’re also working on a set of common libraries to allow you to move more of the logic to common code:

kotlin.test, included out of the box in Kotlin 1.2, lets you write your test once and run it under both the JVM and JS;

kotlinx.html supports isomorphic rendering – using the same code to render HTML in the backend and in the frontend;

kotlinx.serialization allows you to easily marshal Kotlin objects between different tiers of your application, using JSON or ProtoBuf as serialization formats.

Note that multiplatform projects are currently an experimental feature; it means that the feature is ready for use, but we may need to change the design in the subsequent release (and if we do, we’ll provide migration tools for existing code).

Compilation Performance

Over the course of development of 1.2, we’ve put a lot of effort in making the compilation process faster. We’ve already reached approximately 25% improvement over Kotlin 1.1, and we see significant potential for further improvements, which will be released in 1.2.x updates.

The graph below shows the difference in compilation times for two large JetBrains projects built with Kotlin:

Other Language and Library Improvements

We’ve also made a number of smaller improvements to the language and the standard library:

Kotlin Around the World

Since the release of Kotlin 1.1 in March of this year, Kotlin has made huge gains in adoption all around the world. The culmination of that was KotlinConf, our first worldwide conference, with around 1200 attendees gathering in San Francisco on November 2-3rd. We’ve recorded all the talks, and the videos are now available.

Kotlin is now an officially supported language for Android development, with out-of-the-box support in Android Studio 3.0, as well as official samples and style guides published by Google. As a result, Kotlin is already used in more than 17% of projects in Android Studio 3.0, including many apps from the hottest startups as well as Fortune 500 companies.

The community growing around Kotlin is also really amazing. There are over 100 user groups all around the world, and so many talks that we have a hard time keeping track of all of them – but for those that we do know about, the talks map gives you a very good idea of how wide-spread the use of Kotlin really is.

Compatibility. In Kotlin 1.2 the language and the standard library are backwards compatible (modulo bugs): if something compiled and ran in 1.0 or 1.1, it will keep working in 1.2. To aid big teams that update gradually, we provide a compiler switch that disables new features. Here is a document covering possible pitfalls.

This depends on when you want to have results. Sharing Kotlin code between Android and iOS is not quite there yet; it’ll take some more time for us to build the missing pieces. Also, our approach is focused on sharing only business logic between platforms, not UI code. If you want to share UI between platforms, you should look into other technologies.

Do you know about anyone who managed it? I tried to search for some examples but couldn’t find any. Given the rising popularity of RN it would be nice to be able to use it with some saner language than JS

Btw. is there any reason why you guys compile against a huge kotlin.js runtime library in your javascript compile target. Even for things which javascript perfectly fine can handle itself (like classes, inheritance etc…)
I wanted to use kotlin as high level frontend for a js library but the kotlin.js dependency basically prevented that, oh well back to typescript then.

There is much more than one possible set of semantics for classes; both C++ and Java have classes, but they look completely different. In the same way, Kotlin/JS needs to support the Kotlin semantics for classes, and not whatever is supported by JS.

We’ve also built a dead code elimination tool that greatly reduces the size of the standard library dependency in most projects.

You do not have to go to Scala for examples here.
Typescript is the perfectly fine example with its approach of it must be compilable into pure ecmascript on all supported language levels.

class bla {

is compiled against real javascript classes in es6 and higher
and against prototype inheritance in lower dialects of es.
Heck if pure es classes do not do it you always can fall to prototypes which are one level deeper.

But that is just an example. The problem simply is that every compilation relies on a runtime file which is a no go for third party libraries. Kotlin itself is a nice language however and it might be a viable option for many js projects, just not for mine.

I like Java but, man, Kotlin will take its place on the chart in no time. I love Kotlin. Thank you for creating such an awesome language. By the way, do you guys plan on having array, list and map literals like Groovy does?

do you plan to enhance kotlin.test library with compiler-driven mock generation in spirit of Mockito? that would positively impact performance of CI pipelines out there
how about AssertJ-inspired DSL? or Cucumber? do you have a clear roadmap for testing side of kotlin?

We have no plans to build a mock generation library for Kotlin at this time. For fluent assertions, there are quite a few third-party solutions, including hamkrest and kotlintest. Cucumber already works with Kotlin, as far as I understand; the only thing missing is IDE support, which we’ll likely add at some point.

It looks like a very promising language, and I’m eager to start using it in my projects. Compatible and in many ways better than Java, and a suitable replacement for Javascript – the promise of unifying the front-end and back-end with a single programming language is a very powerful concept.

What’s missing: better IDE support. If we don’t have reliable code-completion, syntax checking, snippets, etc, we’re back in the 90s. I won’t change programming language until this is fixed. The IDEA support is understandably better, but all other IDEs are treated as distant cousins – specially Netbeans, the plugin seems not to be maintained (last commit from August).

We are focusing heavily on IDE support, and the IDE we’re focusing on is IntelliJ IDEA. The statistics we saw for our NetBeans plugin were so low that unfortunately we cannot invest further into the development of the plugin.