pastedimage0283429
pastedimage0283429


Posted by Ting-Yuan, Software Engineer and Huang David Winer, Product manager

Android image

Today we’re excited to announce the Alpha of Kotlin symbol processing (KSP), a brand new tool for creating compact compiler plugins in Kotlin. KSP provides functionality similar to KAPT, but is up to two times faster, provides direct access to Kotlin compiler functions, and is designed with multi-platform compatibility in mind.

KSP is compatible with Kotlin 1.4.30 and higher. You can check the open source code and documentation in the KSP GitHub repository.

Why KSP?

The first request we hear from Kotlin developers is to speed up the build speed. Many developers iterate and deploy apps dozens of times a day. Hence, waiting for a slow build can be very time consuming. One of the biggest challenges in compiling Kotlin code is that Kotlin does not have a native annotation processing system. Annotation processors like Room are ubiquitous on Android and rely on Java annotation processing compatibility via the Kotlin Annotation Processing Tool (KAPT). However, KAPT can run slowly because of the need to generate intermediate Java stubs which can then be picked up by the Java annotation processing system.

While designing KSP, we thought about what the processing of annotations for Kotlin would look like if we created it from scratch. KSP provides a powerful yet simple API for parsing Kotlin code directly, which dramatically reduces the build speed tax imposed by KAPT’s stub generation. First benchmarks with the room library show that KSP is about 2x faster than KAPT.

Started

Download the KSP playground project from GitHub to see what KSP looks like in action. In it you will find:

  • Library: A toy test-processor Library that implements the builder pattern as a KSP processor
  • Consuming Project: A workload Directory showing how the builder processor is used in a real Kotlin project

All of the logic to implement the builder is in test-processor – for the consumer (workload) the only difference between using KAPT and KSP is a two-line change to the build file:

This is KSP’s goal: most Android app developers don’t have to worry about the internals. Aside from this one-line change, a library that supports KSP looks like a regular annotation processor, only it’s up to two times faster. However, using KAPT and KSP in the same module will likely slow down your build at first. In this alpha phase, it is therefore best to use KSP and KAPT in separate modules.

As more and more annotation processors use KSP, we expect that most of your modules will be able to use KSP as a near drop-in replacement for KAPT. You can first use this table to check which annotation processors offer KSP support. If a library that supports or implements support for KSP is missing from the table, please send a pull request with your suggestion!

If you are the author of a library that currently uses annotation processing, please refer to the Quick Start and README guides for more information on how to make your library compatible with KSP.

Now that KSP is in alpha, now is a good time for library writers to take a closer look at this and give us feedback on the API in the KSP Issue Tracker. In addition, we regularly publish release updates in the #ksp channel on Kotlin Slack. Since the Developer Preview last June, we’ve fixed over 100 bugs and issues, dozens of which have been reported by the amazing Kotlin library developer community.

Java is a registered trademark of Oracle and / or its affiliates.



LEAVE A REPLY

Please enter your comment!
Please enter your name here