For those of you who have gone through the migrati...
# compiler
m
For those of you who have gone through the migration process to the K2 compiler, what did you do about KAPT based plugins? I'm working on removing it as much as I can, but i'd rather not have the compiler fallback to language version 1.9 just because of kapt. I'm mostly encountering issues related to legacy code with databinding enabled.
Copy code
w: Kapt currently doesn't support language version 2.0+. Falling back to 1.9.
The other option is to enable `kapt.use.k2`:
Copy code
w: K2 kapt is an experimental feature. Use with caution.
Doesn't exactly give me warm fuzzies
z
K2 kapt works great for us
t
using ksp instead is the general recommendation i've seen
m
Thanks @Zac Sweers. Like I said, it's mostly data binding. That's the issue. The life cycle compiler works under KSP. And I'm using your plug-in for the auto value processor under KSP.
As well as the forked anvil compiler
z
yah we've had no issues with K2 kapt since kotlin 2.1. It was also a good deal faster
m
I think we're still on the 2.0 plug-in but we should be updating that soon. The guy who normally handles that is on vacation
n
Hey @Zac Sweers, we're also moving towards Kotlin 2 and KSP. We are currently thinking about it's approach, 1. Move from KAPT to KSP module by module, then move to Kotlin 2.x.x 2. Move to Kotlin 2.x.x while using KAPT with K2 Can you please share your POV, and what was the reasoning you still kept KAPT? I guess you had some libraries which you didn't want to upgrade/remove and they were still not supported via KSP?
z
K2 kapt works, if you have annotation processors that only work in kapt then it's fine. If you have processors that work in KSP, it's less load on your build system if you can move them all over to be on KSP
dagger-ksp has some performance issues in very large codebases with hundreds of modules being consumed by a component, but that's the only issue I found. TL;DR benchmark your build