Kotlin 1.2 Beta2 adds missing pieces to multiplatform project narrative

Gabriela Motroc
Kotlin 1.2

© Shutterstock / enterlinedesign

It’s time for a new Beta release! Kotlin 1.2 Beta2 brings compiler performance improvements, as well as numerous improvements regarding multiplatform projects support, mainly in IDE, but not only.

What’s new in Kotlin 1.2 Beta2?

The second beta brings four new features in the multiplatform projects area (and a bunch of fixes), one new compiler feature (plus a performance improvement and some fixes), one IDE feature and more.

The complete changelog since 1.2-Beta can be found here. Keep in mind that this release also includes the fixes and improvements from the previous 1.2-Beta release.

Multiplatform projects

Annotations for writing multiplatform unit tests

JetBrains’ Dmitry Petrov wrote in a blog post announcing the second Beta release that it is now possible to write tests in a common project so that they will be compiled and run in each platform project.

There are 4 annotations provided in kotlin-test package to markup tests in common code: @Test@Ignore@BeforeTest and @AfterTest.
In JVM platform, they are mapped to the corresponding JUnit 4 annotations and in JS they are already available since 1.1.4 to support JS unit testing.

You will need to add a dependency on kotlin-test-annotations-common to your common module, on kotlin-test-junit to your JVM module, and on kotlin-test-js to the JS module.

SEE ALSO: Can Kotlin overtake Java for Android development? New report says yes

“implement” is renamed to “expectedBy”

Following the expect/actual naming, the Gradle dependency configuration implement (that is used by platform projects to point at their corresponding common project) is now renamed to expectedBy.

The old name has been deprecated.

dependencies {
    expectedBy project(':lib-common')

Correct importing of multiplatform projects with multiple modules

The JetBrains team also solved an issue with references to common code in a platform module being unresolved in a multiplatform project with multiple modules. The bottom line is that you don’t have to add extra dependencies manually to make these references resolved anymore.

Gradle plugin

“warningsAsErrors” is renamed to “allWarningsAsErrors”

The warningsAsErrors flag that was introduced in Kotlin 1.2 Beta has been renamed to allWarningsAsErrors :

compileKotlin.kotlinOptions.allWarningsAsErrors = true

Standard library

“Closeable.use” calls “Throwable.addSuppressed” when available

Closeable.use function calls Throwable.addSuppressed when an exception was thrown during closing the resource after some other exception. However, make sure you have kotlin-stdlib-jdk7 in your dependencies — otherwise, you can’t enable this behavior.

We haven’t covered all the significant changes so if you want to have a look at them, read Petrov’s blog post


Update October 2, 2017

Look what the cat dragged in! The major new feature — experimental support for multiplatform projects.

As far as tooling is concerned, Kotlin 1.2 beta includes the same set of features as 1.1.50 update. The language and standard library are now feature complete – all the new features planned for Kotlin 1.2 have been implemented, according to the blog post announcing the beta. The beta is compatible with all versions of IntelliJ IDEA from 2016.3 until 2017.3, as well as with Android Studio 2.3 and 3.0.

Kotlin 1.2 beta overview

Multiplatform projects

This major new feature in Kotlin 1.2 allows users to reuse code between target platforms supported by Kotlin, namely JVM, JavaScript for now and Native in the future. JetBrains’ Roman Belov explained that in a multiplatform project, “you put code which is shared between platforms into a common module, and platform-dependent parts into platform-specific modules that depend on it. When you compile such a project for a specific platform, the code for both the common and platform-specific parts is generated.”

A key feature of the multiplatform project support is the possibility to express dependencies of common code on platform-specific parts through expected and actual declarations. An expected declaration specifies an API (class, interface, annotation, top-level declaration etc.). An actual declaration is either a platform-dependent implementation of the API or a typealias referring to an existing implementation of the API in an external library.

If you want to read more about this new experimental feature in Kotlin 1.2, check out the documentation.

Support for array literals in annotations

Support for array literals in annotations is a new language feature in Kotlin 1.2 — this means that instead of writing something like @CacheConfig(cacheNames = arrayOf("books", "default")), you can simply use a literal expression:

@CacheConfig(cacheNames = ["books", "default"])

Although this feature became available in previous milestone releases of Kotlin 1.2, the syntax is now more consistent and allowed to use array literals both for array and for varargparameters:

@RequestMapping(value = ["value1", "value2"], path = ["path1", "path2"])

JetBrains has make some adjustments to the syntax of using named arguments together with varargs — both in regular method calls and in annotations — in order to enable the change.

SEE ALSO: Kotlin cheat sheet: Tips & tricks

lateinit improvements

There’s also a new reflection API which allows you to check whether a lateinit variable has been initialized. This is a partial implementation of this KEEP proposal. The deinitializemethod — the remaining part— has been postponed but it might make its debut in Kotlin 1.3., according to Belov.

Here’s the proposal.

Warnings as errors

The compiler now offers an option to treat all warnings as errors. You can use -Werror on the command line, or the following Gradle snippet:

compileKotlin {
  kotlinOptions.warningsAsErrors = true

Standard library

Split package compatibility

Good news! The Kotlin standard library is now fully compatible with the Java 9 module system, which forbids split packages (multiple jar files declaring classes in the same package), Belov explained. JetBrains created new artifacts kotlin-stdlib-jdk7 and kotlin-stdlib-jdk8, which replace the old kotlin-stdlib-jre7 and kotlin-stdlib-jre8.

You can see the declarations in the new artifacts under the same package names from the Kotlin point of view. However, they are visible under different package names for Java. As a result, if you want to switch to the new artifacts, you won’t have to make any changes to your source code.

Furthermore, they removed the deprecated declarations in the kotlin.reflect package from the kotlin-reflect library. Keep in mind that you must switch to using the declarations in the kotlin.reflect.fullpackage if you were using them.

SEE ALSO: RebelLabs Developer Productivity Report: Users most satisfied with Spring, Kotlin & NetBeans IDE


kotlin.math is a new package in the Kotlin 1.2 standard library which allows you to perform mathematical operations in cross-platform code. Several improvements have been made in 1.2-Beta:

  • Inverse hyperbolic functions (asinhacoshatanh) are now supported
  • Functions related to binary representation of floating point numbers (toBitsnextUp and so on), added in 1.2-M2, are now available for JavaScript
  • Improved precision of math polyfills for JavaScript


Anything introduced in milestone releases of 1.2 is subject to change before the final 1.2 release. 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 or 1.2-Beta.

However, all the code compiled by 1.1.x and earlier releases is perfectly fine without recompilation.

Check out the complete changelog since 1.2-M2 here and Roman Belov’s blog post here

Gabriela Motroc
Gabriela Motroc is an online editor for Before working at S&S Media she studied International Communication Management at The Hague University of Applied Sciences.

comments powered by Disqus