\n
![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEhZN8ICjCu1JRBCumZD-9CK6dV9Gq4fAkEe2lpsTao7njxZ64zVsBoWZc-UID_okfol4yS-AkKb2TPF0PT-7NvLw19xi9yoDRXSN0YfDZZuRbujrkpmVmB5u890diZPx0slqcAPeLxlK2oe1UAkY2IMdbD-NEwdHNHvyy_KPcrdBGuQ8Y4t6gALR69zyII\/s1600\/editorial-Ksp2-Preview-Kotlin-K2-social.png\")
<\/p>\nPosted by Ting-Yuan Huang \u2013 Software Engineer, and Jiaxiang Chen \u2013 Software Engineer The Kotlin Symbol Processing (KSP) tool provides a high-level API for doing meta-programming in Kotlin. Many tools have been built on KSP, enabling Kotlin code to be generated at compile time. For example, Jetpack Room uses KSP to generate code for accessing the database, based on an interface provided by the developer, like:<\/p>\n KSP provides the API to the Kotlin code so that Room in this case can generate the actual implementation of that interface. While KSP has become a core foundation for meta-programing in Kotlin, its current implementation has some gaps which we are aiming to resolve with a new KSP2 architecture. This blog details those architectural changes and the impact for plugins built on KSP.<\/p>\n In addition, KSP2 has preview support for:<\/p>\n After getting feedback on the new architecture and continuing to address gaps we will work towards releasing KSP 2.0 where these changes will be the default.<\/p>\n The new preview changes can be enabled in KSP 1.0.14 or newer using a flag in gradle.properties<\/span>:<\/p>\n Note: You might need to enlarge the heap size of the Gradle daemon now that KSP and processors run in the Gradle daemon instead of the Kotlin compiler\u2019s daemon (which has larger default heap size), e.g. org.gradle.jvmargs=-Xmx4096M -XX:MaxMetaspaceSize=1024m<\/span><\/p>\n Internally KSP2 uses the Beta Kotlin K2 compiler (which will be the default compiler in Kotlin 2.0). You can use KSP2 before switching your Kotlin compiler to K2 (via the languageVersion<\/span> setting) but if you want to use K2 for compiling your code, check out: Try the K2 compiler in your Android projects<\/a>.<\/p>\n KSP1 is implemented as a Kotlin 1.x compiler plugin. Running KSP requires running the compiler and specifying KSP and its plugin options. In Gradle, KSP\u2019s tasks are customized compilation tasks, which dispatch real work to KotlinCompileDaemon<\/span> by default. This makes debugging and testing somewhat difficult, because KotlinCompileDaemon<\/span> runs in its own process, outside of Gradle.<\/p>\n In KSP2, the implementation can be thought of as a library with a main entry point. Build systems and tools can call KSP with this entry point, without setting up the compiler. This makes it very easy to call KSP programmatically and is very useful especially for debugging and testing. With KSP2 you can set breakpoints in KSP processors without having to perform any other \/ irregular setup tasks to enable debugging.<\/p>\n Everything becomes much easier because KSP2 now controls its lifecycle and can be called as a standalone program or programmatically, like:<\/p>\n With the new implementation, it is also a great opportunity to introduce some refinements in the API behavior so that developers building on KSP will be more productive, have better debuggability and error recovery. For example, when resolving Map<\/span><<\/span>String,<\/span> NonExistentType<\/span>><\/span>, KSP1 simply returns an error type. In KSP2, Map<\/span><<\/span>String,<\/span> ErrorType<\/span>><\/span> will be returned instead. Here is a list of the current API behavior changes we plan on making in KSP2:<\/p>\n KSP1:<\/b><\/span> The whole type will be an error type due to failed type resolution<\/p>\n KSP2:<\/b><\/span> It will successfully resolve the container type, and for the non-existent type in the type argument, it will correctly report errors on the specific type argument.<\/p>\n<\/li>\n KSP1:<\/b><\/span> No bounds<\/p>\n KSP2:<\/b><\/span> An upper bound of Any?<\/span> is always inserted for consistency<\/p>\n<\/li>\n KSP1:<\/b><\/span> Expanded to the underlying, non-alias type<\/p>\n KSP2:<\/b><\/span> Not expanded, like uses in other places.<\/p>\n<\/li>\n KSP1:<\/b><\/span> Constructors have FQN if the constructor is from source, but not if the constructor is from a library.<\/p>\n KSP2:<\/b><\/span> Constructors do not have FQN<\/p>\n<\/li>\n KSP1:<\/b><\/span> Inner types has arguments from outer types<\/p>\n KSP2:<\/b><\/span> Inner types has no arguments from outer types<\/p>\n<\/li>\n KSP1:<\/b><\/span> Star projections have type arguments that are expanded to the effective variances according to the declaration sites.<\/p>\n KSP2:<\/b><\/span> No expansion. Star projections have null<\/span>s in their type arguments.<\/p>\n<\/li>\n KSP1:<\/b><\/span> Java Array has a invariant upper bound<\/p>\n KSP2:<\/b><\/span> Java Array has a covariant upper bound<\/p>\n<\/li>\n KSP1:<\/b><\/span> An enum entry has its own subtype with a supertype of the enum class (incorrect behavior from language point of view)<\/p>\n KSP2:<\/b><\/span> An enum entry’s type is the type of the enclosing enum class<\/p>\n<\/li>\n For example<\/p>\n KSP1:<\/b><\/span><\/p>\n KSP2:<\/b><\/span><\/p>\n DFS order, first super type found overridden symbols (with recursive super type look up) in direct super type list is returned.<\/p>\n For the example, KSP will say OverrideOrder1.foo()<\/span> overrides GrandBaseInterface1.foo()<\/span> and OverrideOrder2.foo()<\/span> overrides GrandBaseInterface2.foo()<\/span><\/p>\n<\/div>\n<\/li>\n KSP1:<\/b><\/span> Transient\/volatile fields are final by default<\/p>\n KSP2:<\/b><\/span> Transient\/volatile fields are open by default<\/p>\n<\/li>\n KSP1:<\/b><\/span> Type annotations on a type argument is only reflected on the type argument symbol<\/p>\n KSP2:<\/b><\/span> Type annotations on a type argument now present in the resolved type as well<\/p>\n<\/li>\n KSP1:<\/b><\/span> Considered an Array type<\/p>\n KSP2:<\/b><\/span> Not considered an Array<\/span> type<\/p>\n<\/li>\n KSP1:<\/b><\/span> values<\/span> and valueOf<\/span> are missing if the enum is defined in Kotlin sources<\/p>\n KSP2:<\/b><\/span> values<\/span> and valueOf<\/span> are always present<\/p>\n<\/li>\n KSP1:<\/b><\/span> componentN<\/span> and copy<\/span> are missing if the data class is defined in Kotlin sources<\/p>\n KSP2:<\/b><\/span> componentN<\/span> and copy<\/span> are always present<\/p>\n<\/li>\n<\/ol>\n When it comes to the processing scheme, i.e. what sources are processed when, the principle of KSP is to be consistent with the build’s existing compilation scheme. In other words, what the compiler sees is what processors see, plus the source code that is generated by processors.<\/p>\n
\n<\/em><\/p>\n![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEgciES-nL42T_uDeCEbNwdhYjKVh5FB9t8S-QJL8tr9eQu4h89A9fflFVFwEisju1Ii2g9YnRiHxgBoHNVzRFX_1W9pLqe2JP7vYYB0KmXeLt6LdQNa7IhwUvC_UXqEpKdOht_jG4yLQeVahycd8g_Zw2rxp6ccjFT97borB2Ivorh9yrHxhKZI9aqyLsw\/s1600\/Ksp2-Preview-Kotlin-K2-Banner.png\")
<\/a><\/p>\n@Dao\ninterface<\/span> UserDao {\n @Query(\"SELECT * FROM user\"<\/span>)\n fun<\/span> getAll<\/span>(): List<User>\n}\n<\/pre>\n<\/div>\n\n
\n
Enabling the KSP2 Preview<\/h3>\n
KSP2 and K2<\/h3>\n
Standalone Source Generator<\/h3>\n
val<\/span> kspConfig = KSPJvmConfig.Builder().apply {\n \/\/ All configurations happen here.<\/span>\n}.build()\nval<\/span> exitCode = KotlinSymbolProcessing(kspConfig, listOfProcessors, kspLoggerImpl).execute()\n<\/pre>\n<\/div>\nKSP2 API Behavior Changes<\/h3>\n
\n
interface<\/span> GrandBaseInterface1 {\n fun<\/span> foo<\/span>(): Unit\n}\n\ninterface<\/span> GrandBaseInterface2 {\n fun<\/span> foo<\/span>(): Unit\n}\n\ninterface<\/span> BaseInterface1 : GrandBaseInterface1 {\n}\n\ninterface<\/span> BaseInterface2 : GrandBaseInterface2 {\n}\n\nclass<\/span> OverrideOrder1<\/span> : BaseInterface1, GrandBaseInterface2 {\n override<\/span> fun<\/span> foo<\/span>() = TODO()\n}\nclass<\/span> OverrideOrder2<\/span> : BaseInterface2, GrandBaseInterface1 {\n override<\/span> fun<\/span> foo<\/span>() = TODO()\n}\n<\/pre>\n<\/div>\n
\nFor the example, KSP will say OverrideOrder1.foo()<\/span> overrides GrandBaseInterface2.foo()<\/span> and OverrideOrder2.foo()<\/span> overrides GrandBaseInterface1.foo()<\/span><\/p>\nNew Multiplatform Processing Scheme<\/h3>\n