Hello, I want to know if the Kotlin team has a com...

# compiler

[Ximing Chen]

Hello, I want to know if the Kotlin team has a compatibility roadmap for AGP? As we know, AGP 8 completely removed the Transform API, but in my team, because some plug-in use cases cannot be implemented in AGP 8, the large number of API changes to upgrade AGP are also quite difficult to adapt, causing us to be stuck in the AGP 7 version (currently 7.0, we will try to migrate to 7.4). If Kotlin stops supporting AGP 7 compatibility, upgrading to a new version of Kotlin will become more difficult.😢

[mbonnin]

This is probably more for #C19FD9681?

[Pablichjenkov]

Worth mentioning Gradle has a slack workspace itself.
Handle: gradle-community

[mbonnin]

Yes! Although this question would fit perfetctly this slack IMO

[mbonnin]

Most questions don't but this one is very KGP specific so I'd say it's a good candidate for #C19FD9681

[mbonnin]

Which I'm advocating for renaming to #kotlin-gradle-plugin

[Pablichjenkov]

I agree Martin

[Pablichjenkov]

I did also struggle with Gradle 7 to Gradle 8 migration. For the same reason, the removal of the transform API. It was a big task

[ephemient]

for us, rewriting multiple transforms to the newer API took about 1 day. and we had 4 of them iirc

[ephemient]

regardless, at some point in the future you definitely will need to upgrade AGP for newer Kotlin. https://issuetracker.google.com/issues/259523353

[Ximing Chen]

As far as I know, the most powerful API in AGP 8 [toTransform] cannot get compilation speed optimization, nor does it support incremental compilation. In fact, they mainly optimized a few specific use cases such as ASM bytecode modification, but removed the entire Transform API. Writing plugins based on the toTransform API has become more difficult and cannot support all use cases. (https://juejin.cn/post/7222091234100330554 & https://issuetracker.google.com/issues/219002669)

[Ximing Chen]

Our team actually encapsulated a powerful framework based on the Transform API. The output of all plug-ins based on this framework will be written to the same place, thus avoiding the disk I/O performance bottleneck when running the Transform API sequentially (the same concept as the optimization in AGP 8, but the framework existed when AGP 3 was still the mainstream version!), all plug-ins implemented based on the Transform API can continue to be used after simple modifications, and support incremental builds of Transform. We have written dozens of plug-ins based on this framework, so it is difficult to complete the migration of the plug-in system. We and many companies are still waiting for Google to launch an alternative use case for the Transform API, but Google said "There is no single replacement for the Transform API", which greatly increases the complexity of the migration process and increases the compilation time of our applications.