days
-4
-2
hours
0
-7
minutes
-5
-5
seconds
-4
-5
search

Kotlin 1.2.60 adds optional expected annotations to multiplatform projects

Gabriela Motroc
Kotlin

© Shutterstock / Michael.P

Kotlin 1.2.60, the newest bugfix and tooling update for Kotlin 1.2 brings a lot of goodies, including optional expected annotations to multiplatform projects, experimental kapt mode aimed to speed up Gradle builds, new refactorings, inspections, and intentions to the IntelliJ IDEA plugin and more. Let’s take a look at what’s in this update.

Kotlin 1.2.60 arrives with exciting changes in tow, including optional expected annotations to multiplatform projects, experimental kapt mode aimed to speed up Gradle builds, new refactorings, inspections, and intentions to the IntelliJ IDEA plugin and more.

As usual, you’ll find the complete list of changes in the changelog.

Kotlin 1.2.60 highlights

Multiplatform projects update

Optional expectation for annotations

Kotlin 1.2.60 adds the @OptionalExpectation annotation, which will come in handy when marking expect annotation class declarations in common code whose actual counterparts may be omitted in the platform implementations. This will make the compiler ignore the annotations on the common declarations during compilation of the platform modules that have no corresponding actual annotation class, according to the blog post announcing the new update.

The biggest benefit is that you will be able to use annotations such as @JvmName and @JsName in common code of a multiplatform project. These annotations will be offered in kotlin-stdlib-common starting with 1.2.70.

Building a multiplatform project with IntelliJ IDEA

You can build a multiplatform project with the integrated build system of IntelliJ IDEA without delegating the task to Gradle, thus improving build times for IDE run configurations. These builds already benefit from incremental compilation of Kotlin code.

Kapt improvements

There’s now an experimental option to run kapt, the Kotlin annotation processing tool, directly using Gradle workers. In some cases, this may significantly improve the overall build speed.

If you want to switch to the Gradle worker implementation, all you have to do is add the kapt.use.worker.api=true key to the gradle.properties file. However, this is only available with Gradle 4.3 and above. The team plans to enable it by default in Kotlin 1.2.70, so make sure to give them your feedback.

Furthermore, information messages produced by the annotation processors used with kapt, which were shown as warnings in Gradle builds, are now printed with the INFO logging level for cleaner build outputs. If you’d like to revert to the old behavior and print them as warnings, you need to set the Gradle project property kapt.info.as.warnings to true in the gradle.properties file.

IntelliJ IDEA support improvements

  • There’s a new quick fix for wrapping a value into a singleton list, set, array, or sequence on type mismatch and corresponding postfix templates for the functions listOfsetOfarrayOfsequenceOf
  • A quick fix for removing the lateinit modifier when it conflicts with a custom property accessor
  • A quick fix to either move a const val property into the companion object or remove an illegal const modifier
  • An intention for replacing String.format(...) with a string template
  • Other useful inspections and intentions
  • Lots of bug fixes and performance improvements

New deprecations

New checks were added for the following erroneous constructs:

  • Smart casts of local delegated properties that led to type safety guarantees violation and runtime failures (KT-22517)
  • Annotation arguments erroneously accepted even though they are not compile time constants (KT-23153)
  • Java static member usages that were inconsistent with Kotlin companion object members visibility (KT-25333)
  • Annotations with EXPRESSION target and non-SOURCE retention (KT-13762)

Keep in mind that the above-mentioned deprecations are reported as warnings in Kotlin 1.2.60+ and will become errors in Kotlin 1.3. The corresponding checks already report errors in the progressive compiler mode (with the -Xprogressive flag).

To update your IntelliJ IDEA or Android Studio plugin, use Tools | Kotlin | Configure Kotlin Plugin Updates and click the “Check for updates now” button. You’ll also have to update the compiler and standard library version in your Maven and Gradle build scripts.

 

Update June 14, 2018

Long time no see! It’s been almost two months since Kotlin 1.2.40 was released but the newest update was surely worth the wait.

Kotlin 1.2.50 brings a lot of goodies, including updated Kotlin support in the Eclipse IDE plugin, new functions in common and JS parts of the standard library, JUnit 5 support to kotlin.test, improved experimental scripting support, Runnable Kotlin scratch files in IntelliJ IDEA, a progressive compiler mode, updated experimental @JvmDefault support with a binary compatibility mode and more.

As usual, if you want to update your IntelliJ IDEA or Android Studio plugin, all you have to do is use Tools | Kotlin | Configure Kotlin Plugin Updates and click the ‘Check for updates now’ button. You can install or update the Eclipse IDE plugin via the Eclipse Marketplace.

Friendly reminder: You should also update the compiler and standard library version in your Maven and Gradle build scripts.

Kotlin 1.2.50 highlights

Eclipse IDE plugin update

Things are moving forward! The new 0.8.5 release of their plugin for the Eclipse IDE brings a number of features and improvements, including support for the Kotlin 1.2.50 compiler, according to the blog post announcing Kotlin 1.2.50.

The list of features and improvements includes support for the Kotlin compiler plugins like kotlin-allopen and kotlin-spring, some bugfixes in the debugger and J2K converter, as well as preferences in configuring the version of the generated JVM bytecode.

You’ll find the workspace-wide Kotlin compiler preferences in Preferences | Kotlin | Compiler. By the way, you can also configure only project-level settings.

Library updates

The common and Kotlin/JS parts of the standard library have company: a set of toString(radix: Int) extension functions for ByteShortInt, and Longhas just been added and is ready to be used in experimental multiplatform projects and projects targeting JavaScript. But that’s not all; the common and Kotlin/JS parts of the standard library also received two constructors, namely String(chars: CharArray) and String(chars: CharArray, offset: Int, length: Int) meant for efficient conversion of a CharArray to String.

Furthermore,  the kotlin.test library now supports testing with the JUnit 5 framework with a separate module kotlin-test-junit5, which provides an implementation of Asserter on top of JUnit 5 and maps the test annotations from kotlin-test-annotations-common to the JUnit 5 test annotations.

Improved experimental scripting support

Kotlin 1.2.50 also brings new experimental scripting support which allows easier kotlin scripts customization, simpler use of the scripts with standard compiler and IDEA plugin, and simpler scripting host creation and embedding.

You’ll find the complete Kotlin scripting proposal, as well as the current implementation state in the appropriate KEEP.

IntelliJ IDEA plugin improvements

Runnable Kotlin scratch files and Kotlin scripts

The update of the Kotlin IntelliJ IDEA plugin introduces support for runnable Kotlin scratch files, which can use the declarations from the code in the project.

There’s also improved IDE support for Kotlin Script (*.kts) files, which means you can now create new scripts in the Project View and run them within the classpath of the module they are placed in.

Raw strings input and indentation

Typing raw string literals has never been easier; thanks to the updated IDE plugin, the pairing """ is inserted automatically; it also provides an intention to indent the literal.

This improvement will come in handy when you paste a multiline string.

Faster Gradle builds and annotation processing

Starting with this release, Kotlin tracks changes incrementally across the modules of a multimodule Android project. This translates into faster incremental builds of large Android projects with multiple interdependent modules.

This update improves the performance of annotation processing with kapt. There’s also an experimental option to run annotation processing directly using Gradle workers, which may significantly improve the overall build speed -in some cases.

If you want to switch to the Gradle worker implementation, all you need to do is add the kapt.use.worker.api=true key to the gradle.properties file.

Friendly reminder: It is only available with Gradle 4.3 and above.

Changes in the compiler

Progressive compiler mode

Most bugs and inconsistencies found in the Kotlin compiler are fixed as soon as possible but you should keep in mind that some of the fixes may potentially be backward-incompatible. The Kotlin compatibility policy requires the team to introduce such fixes only in major releases (such as 1.1 and 1.2) and go through lengthy migration cycles. However, if these bugfixes were delivered faster, the code would be safer and cleaner.

Kotlin 1.2.50 introduces an experimental progressive compiler mode intended for actively developed codebases whose maintainers regularly update to latest versions of the Kotlin compiler and tools. According to the blog post announcing the release, “in this mode, some of the deprecations and bug-fixes for unstable code take effect immediately. Consequently, some code may break upon enabling the mode or upon updating Kotlin to future versions while keeping the progressive mode enabled. Fixes that are chosen to be enabled in the progressive mode won’t affect too many places in the codebases, though they won’t work silently and will require the maintainers to fix the erroneous pieces of code.”

But fear not; they will provide automated migration tools in the IDE plugin for this where possible. What’s more, code fixed in this way will remain valid outside the progressive mode.

The progressive mode can be enabled on a per-module basis by adding the flag -Xprogressive to the arguments passed to the Kotlin compiler.

@JvmDefault binary compatibility mode

Experimental support for generating default methods for JVM interfaces with @JvmDefault has been updated to compile the default methods in a way that is binary-compatible with normal default implementations in Kotlin interfaces. Use the compiler flag -Xjvm-default=compatibility if you want to switch to this mode.

By the way, the compiler flag -Xenable-jvm-default introduced in Kotlin 1.2.40 is no longer supported so use -Xjvm-default=enable instead.

Argument files

The latest release also supports passing compiler arguments in a file with the command line option -Xargfile=args.txt, which helps call the command line compiler with long filesystem paths in the arguments.

You’ll find the complete list of changes in the changelog.

 

Update April 20, 2018

There’s a new bugfix and tooling update for Kotlin 1.2 which adds new inspections and intentions to the Kotlin IntelliJ plugin, as well as @JvmDefault annotation which makes interface methods default in Java (experimental).

Furthermore, Kotlin 1.2.40 allows platform modules in experimental multiplatform projects to have more than one expectedBy dependency and enables support for crossinline suspend parameters in inline functions, according to the blog post announcing the update.

Let’s have a look at some of the highlights.

Improvements for multiplatform projects

Platform modules can now reuse the code and provide actual platform-specific implementations for declarations from more than one common module. You can add multiple expectedBy dependencies to the platform module, for example:

apply plugin: 'kotlin-platform-jvm'
// ...
 
dependencies {
    expectedBy project(":io-common")
    expectedBy project(":data-common")
    // ...
}

Since expectedBy dependencies are still non-transitive, if a common module, for example app-common, depends on another one, lib-common, then, in a platform module, you can either provide actual implementations for both, manually specifying the two as expectedBy dependencies, or add an expectedBy dependency on just app-common and a compile dependency on an existing platform module for lib-common.

The support for default parameters in expect functions and constructors has also been improved:

expect class StringMatcher {
    fun match(value: String, matchStrictly: Boolean = false): Boolean
}

However, keep in mind that you shouldn’t specify default parameter values for the actual counterparts since they are only allowed in expect declarations.

Crossinline suspend function parameters

Kotlin 1.2.40 enables support for inline function crossinline parameters of suspend function types, which can then be called inside nested suspending functions and lambdas:

inline fun schedule(crossinline runner: suspend () -> Unit)  {
    launch(CommonPool) {
        runner()
    }
}

Support declaring Java default interface methods

Kotlin 1.2.40 brings experimental support for generating default interface methods for the JVM target 1.8 and above. Although this feature is disabled by default, it can be enabled by passing a compiler flag -Xenable-jvm-default. Then an interface member with a body can be marked with the @JvmDefault annotation (from the kotlin.jvm package):

interface Foo {
    @JvmDefault
    fun foo(): Int = 0
}

This functionality is experimental in Kotlin 1.2.x, so its design and implementation may change in future updates.

Visibility restrictions for types brought into scope through companion objects subtyping

Kotlin 1.2.40 introduces deprecation warnings and migration tools in the IDE plugin to make sure the migration is as smooth as it can be when it comes to potentially breaking changes in Kotlin 1.3 regarding classifiers visible through companion objects.

When a body of a type Foo uses a short (non-qualified) type name which is declared in a supertype of Foo‘s own companion object, or in the companion objects of Foo‘s supertypes, as well as in the supertypes of these companion objects, without a proper import statement, you’ll receive a warning with a quick-fix that adds the import.

In Kotlin 1.3, these short names will be invisible unless they are qualified or imported.

IntelliJ IDEA plugin improvements

There’s a new intention for adding and removing explicit labeled return for the result expressions in lambdas:

The list of improvements doesn’t stop here. Kotlin 1.2.40 brings new intentions for adding and removing annotation use-site targets, an inspection to highlight and remove unnecessary explicit companion object references, as well as a bunch of stability and performance improvements.


Here’s how to update the plugin: Tools → Kotlin → Configure Kotlin Plugin Updates and go to Check for updates now. You’ll also have to update the compiler and standard library version in your Maven and Gradle build scripts.

 

Update March 6, 2018

Kotlin 1.2.30 is here.

According to the blog post announcing the bugfix and tooling update, Kotlin 1.2.30 adds a new declaration in the standard library, which imitates the suspend modifier for lambda expression and there’s also support for TestNG inkotlin.test.

The new update brings support for Android modules in multiplatform projects and introduces a new feature in kapt for reporting annotation processing errors along with proper links to the original Kotlin declarations. Bugs in the compiler and IntelliJ plugin have been fixed and plenty of new inspections and intentions have been added to the IntelliJ plugin.

Kotlin 1.2.30 is compatible with all versions of IntelliJ IDEA from 2017.1 until 2017.3 and 2018.1 EAP, as well as with Android Studio 3.0.

Kotlin 1.2.30 highlights

Library changes

As we mentioned above, Kotlin 1.2.30 adds a new function to the Kotlin standard library with the following signature:

public inline fun <R> suspend(
    noinline block: suspend () -> R
): suspend () -> R = block

This function wraps a function literal into a value of a suspending function type and enables its usage as a suspending function.

Keep in mind that a suspend modifier for lambda expressions will be gradually introduced in the future Kotlin versions, and adding this function is the first step.

Thanks to Valeriy Zhirnov, another notable change is the support for the TestNG framework in kotlin.test. The new artifact kotlin-test-testng provides an implementation of Asserter on top of TestNG and maps the test annotations from kotlin-test-annotations-common to the TestNG test annotations.

Platform modules targeting Android

The update of the experimental multiplatform projects feature introduces support for Android platform modules. These modules should apply the corresponding plugin in the Gradle build script and can use the shared code from a common module:

apply plugin: 'com.android.application'
apply plugin: 'kotlin-platform-android'
// ...

dependencies {
    expectedBy project(":multiplatform-app")
    // ...
}

Kapt diagnostic locations

As of now, kapt, the Kotlin annotation processing tool, can offer links to locations in the original Kotlin code rather than generated Java stubs as it reports errors encountered during annotation processing. You can enable this feature by adding these lines to the Gradle build script (build.gradle):

kapt {
    mapDiagnosticLocations = true
}

IntelliJ IDEA plugin improvements

Kotlin 1.2.30 brings various improvements in the IntelliJ IDEA Kotlin plugin, including performance improvements, bug fixes, and new inspections and intentions. Furthermore, you can now paste Kotlin code into a package item in the Project View, creating a new Kotlin file for the code:

You can find the complete list of changes in the changelog.

 

Update January 17, 2018

Kotlin 1.2.20 is here. This bugfix and tooling update for Kotlin 1.2 is compatible with all versions of IntelliJ IDEA from 2017.1 until 2017.3, and also with Android Studio 3.0 and 3.1 Canary.

Dmitry Jemerov, Principal Engineer at JetBrains wrote in the blog post announcing the update that it:

  • Adds support for Gradle build cache
  • Improves incremental compilation for Android and mixed Kotlin/Java projects
  • Provides IDE support for the new Kotlin style guide
  • Adds inlay hints in the editor for implicit parameters and receivers of lambdas, as well as values returned from lambdas
  • Supports development mode in JavaScript DCE Gradle task
  • Introduces new inspections, performance improvements and bug fixes in the IntelliJ plugin

Check out the changelog if you’re interested in the complete list of changes.

SEE ALSO: Kotlin 1.2: Multiplatform projects across the JVM and JavaScript

Compilation performance improvements

In this update, most of the improvements are related to the Gradle plugin. Speaking of, one of the improvements is the support for Gradle build cache.

If you’re using Gradle 4.3 or newer and the build cache is enabled (it’s not by default, requires --build-cache or org.gradle.caching=true), the plugin will reuse compilation results from previous executions of the Kotlin compile task, Jemerov explained.

As mentioned above, “build caching for Kotlin annotation processors is disabled by default because the dependencies of annotation processors cannot be tracked precisely by Gradle, so it may incorrectly reuse results of a previous execution of an annotation processor.”

If you want to enable it anyway, all you need to do is add these lines to the build script:

`kapt {
    useBuildCache = true
}`

Another improvement is more precise tracking of changes in Java files, which allows you to avoid Kotlin recompilation when the changes in Java do not affect Kotlin code.

Keep in mind that this feature is experimental, so you’ll have to add this line to your gradle.properties file if you want to enable it:

kotlin.incremental.usePreciseJavaTracking=true

Last but not least, changes to Android layout XML files no longer cause recompilation of all Kotlin sources. As of now, only Kotlin files that reference properties generated by Kotlin Android Extensions (kotlinx.android.synthetic.*) are recompiled.

The formatter fully supports the new Kotlin style guide

new official Kotlin style guide was recently released, covering the formatting of Kotlin code and the idiomatic use of language and library features. As of now, the formatter fully supports the new style guide. Plus, IntelliJ IDEA inspections can detect (and correct with quick fixes) many style guide violations can be detected.

Keep in mind that the formatting suggested by the new style guide is different from the default formatting previously used by the Kotlin plugin so you’ll have to apply the new guide explicitly in order to avoid unwanted formatting changes. To do that, go to Settings | Editor | Code Style | Kotlin and use the “Set from…” link to choose the code style.

JavaScript DCE development mode

The JavaScript dead code elimination (DCE) plugin will come in handy if you need to reduce the output size of the Kotlin to JavaScript compiler. The DCE process takes a bit of extra time, Jemerov warned, and the output size doesn’t matter during development, so you can now disable dead code elimination.

In order to do that, you’ll have to use the following option:

runDceKotlinJs.dceOptions.devMode = true 

Check out Dmitry Jemerov’s blog post for the complete list of highlights.

Author
Gabriela Motroc
Gabriela Motroc is editor of JAXenter.com and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of