Because of KAPT's performance at our size, I've im...

# compiler

[Ty Smith]

Because of KAPT's performance at our size, I've implemented a similar solution to https://www.droidcon.com/media-detail?video=380953207, where we use Javac to process .class files for annotations coming from kotlinc. It's giving us pretty significant build wins and we're willing to work with the constraints like not referencing generating code directly within the same target.

One problem we've run into with some of our APs is the use of SOURCE retained annotations, so I've been experimenting with a kotlin compiler plugin to rewrite the SOURCE retention to CLASS on annotation definitions. However, through my digging, I've only figured out how to rewrite the ones we define per target, but not consume as jars (3rd party deps, downstream java deps, etc..).

I have two questions I'm hoping someone could give context on or point me towards some resources to help.

1. Is there a way to set a new Class Builder Mode that's used for the default compiler execution, not an explicit call from another plugin like KAPT? This would allow us to set the mode to retain source annotations (like kapt does) and solve the issue, but it doesn't seem like the overrideClassBuilderMode() method is called on a plugin extension using ClassBuilderInteceptorExtension.
2. If 1 is not feasible, is it possible to adjust the retention policy at the consumer callsite of an annotation as opposed to just the definition?
If both are not feasible, I plan on doing some bytecode rewriting all the jars in our build pipeline to adjust source retained ones to class, and combine that with the version I have now that rewrites our own defined versions. This seems overweight though, so hoping I'm overlooking something more simple.

[Ty Smith]

An update.

I've filed a couple issues around this, and in the short term, we have the plugin change the value of ClassBuilderMode to set generateSourceAnnotations via Reflection and then rely on Proguard to strip them down at the end.

This functions as expected and allows us to process Kotlin class files for all annotations in javac APT.

[Zac Sweers]

Probably come up, but why not send proposal PRs to those external deps to make them CLASS? Thinking of uber’s stack I can’t think of many (any?) that would be against this if they weren’t already. Can save yourself the hassle that way