Table of contents
No headings in the article.
Before beginning the debate of KSP vs. KAPT*, I should first tell you all what* “Annotation Processing” is.
What is annotation processing?*
Annotation processing is a technique in Java that allows you to generate code at compile time based on annotations. Annotations are special metadata that you can attach to classes, methods, fields, and other Java elements. Annotation processors are programs that can read and process annotations and generate code based on them.*
Annotation processing is a powerful technique that can be used for a variety of purposes, such as:
Code generation: Annotation processors can be used to generate boilerplate code, such as getters and setters, constructors, and equals() and hashCode() methods. This can save you a lot of time and effort, and it can also help to ensure that your code is consistent and well-formatted.
Error checking: Annotation processors can be used to check for errors in your code, such as missing annotations or incorrect uses of annotations. This can help you catch errors early, before they cause problems in your production code.
Aspect-oriented programming: Annotation processors can be used to implement aspects, which are cross-cutting concerns that can be applied to multiple parts of your code. This can make your code more modular and reusable.
Some popular examples of annotation processors include:
Lombok: Lombok is an annotation processor that can generate a lot of boilerplate code, such as getters and setters, constructors, and equals() and hashCode() methods.
AutoValue: AutoValue is an annotation processor that can generate immutable value classes.
JPA: JPA is a persistence framework that uses annotations to map Java classes to database tables.
Now, coming on to our debate
For a long time, we have been working with the “KAPT” implementation of annotation processing in Android in @Glance (Inmobi). But things got more interesting when Google announced its own “Annotation Processing” API, i.e., “KSP.”
Pardon me if I am confusing you all with the complex jargon of KAPT and KSP.
Let me explain to you all what KAPT and KSP are.
KAPT, which stands for “Kotlin Annotation Processing Tool,” is a very powerful tool to generate additional code during compile time. Even if your processor doesn’t support Kotlin, it will allow you to use the Java Annotation Processor with Kotlin code.
KSP, which stands for “Kotlin Symbol Processing,” is an API that you can use to develop lightweight compiler plugins. KSP provides a simplified compiler plugin API that leverages the power of Kotlin while keeping the learning curve to a minimum.
The advantages of KSP over KAPT are…
1) The major advantages of KSP over KAPT are improved build performance, not being tied to the JVM, a more idiomatic Kotlin API, and the ability to understand Kotlin-only symbols.
2) Unlike kapt, processors in KSP do not see input programs from Java’s point of view. The API is more natural to Kotlin, especially for Kotlin-specific features such as top-level functions.
3) The major libraries that are supported by KSP are Room, Moshi, RxHttp, Koin, Glide, and Hilt and in the recent announcement of Android, they provided the support of KSP to Dagger also 😍 (Article for reference).
4) The gradle build is reduced by half if your build time depends on time currently spent on annotation processing with KAPT. If annotation processing is a major bottleneck, the switch to KSP will yield more significant results.
Limitations of KSP:
1) Not as widely supported as KAPT: KSP is not as widely supported as KAPT, so there may be some plugins or libraries that do not yet support KSP.
2) Not as mature as KAPT: KSP is still under development, so there may be some bugs or instability issues.
3) Potential for bugs: Being newer, KSP might have yet-to-be-discovered edge-case bugs or less comprehensive error handling compared to the battle-tested KAPT. This risk lessens over time, but it’s a factor to consider with early adoption.
Apart from this information, if you guys want to explore this, you may refer to the following provided links:
1) lnkd.in/gpz-jCNn
2) lnkd.in/g8CUF7dD
3) lnkd.in/gH3AQc-c
Overall, the decision of Google to make “Kotlin” the official Android Language can now be understood as the wisest one, as they are launching one great thing after another. Be it Kotlin MultiPlatform or KSP 😍.
Follow @Shubham Singh on LinkedIn for more such technical content.