Posted by Ting-Yuan Huang, Software Engineer and David Winer, Product Manager
Today we are excited to announce the alpha of Kotlin Symbol Processing (KSP), an all-new tool for building lightweight compiler plugins in Kotlin. KSP offers similar functionality to KAPT, however it’s up to 2x faster, offers direct access to Kotlin compiler features, and is being developed with multiplatform compatibility in mind.
KSP is compatible with the Kotlin 1.4.30 release and onwards. You can check out the open source code and documentation in the KSP GitHub repository.
Why KSP?
The #1 request we hear from Kotlin developers is to make build speeds faster. Many developers iterate on and deploy apps dozens of times a day, so having to sit around waiting for a slow build can be very time consuming. One of the biggest challenges with compiling Kotlin code is that Kotlin doesn’t have a native annotation processing system. Annotation processors like Room are ubiquitous on Android and rely on Java annotation processing compatibility through the Kotlin Annotation Processing Tool (KAPT). KAPT can be slow to run, though, since it requires generating intermediate Java stubs that can then be ingested by the Java annotation processing system.
When designing KSP, we thought about what annotation processing would look like for Kotlin if we built it from the ground up. KSP offers a powerful and yet simple API for parsing Kotlin code directly, dramatically reducing the build speed tax imposed by KAPT’s stub generation. Indeed, initial benchmarks with the Room library show that KSP is approximately 2x faster than KAPT.
Getting started
To see what KSP looks like in action, download the KSP playground project from GitHub. In it you’ll find:
- Library: A toy
test-processorlibrary that implements the builder pattern as a KSP processor - Consuming project: A
workloaddirectory that shows how to use the builder processor in a real-world Kotlin project
All of the logic for implementing the builder is in test-processor — for the consumer (workload), the only difference between using KAPT and KSP is a two-line build file change:
This is the goal of KSP: most Android app developers don’t need to worry about its internals; other than this one line change, a library that supports KSP looks just like a normal annotation processor, only it’s up to 2x faster. That said, using KAPT and KSP in the same module will likely slow down your build initially, so during this alpha period, it is best to use KSP and KAPT in separate modules.
As more annotation processors adopt KSP, we expect most of your modules to be able to use KSP as a near drop-in replacement for KAPT. For now, you can check out which annotation processors offer KSP support in this table. If a library that supports or is implementing support for KSP is missing from the table, please submit a pull request with your suggestion!
If you are an author of a library that currently uses annotation processing, you can find more information on how to make your library compatible with KSP in the quickstart and README guides.
For library authors, now that KSP is in alpha, it’s a great time to start looking closely at it and giving us feedback on the API in the KSP issue tracker. In addition, we regularly post release updates in the #ksp channel on Kotlin Slack. Since the developer preview last June, we’ve closed over 100 bugs and issues, dozens of which have been reported by the amazing community of Kotlin library developers.
Java is a registered trademark of Oracle and/or its affiliates.
