KSP Support

[trevjonez]

Some recent PR's landing in dagger seem to be clearing the path to KSP. Obviously they have been publicly vocal about the intent to support that. Similar to the "why KSP doc" the goal driving me to raise this question is getting away from stub generation.

Links for anyone looking to build up some context as to what KSP is and what that dagger work that I think looks like the lead-up is:

• https://github.com/google/ksp
• Create dagger.spi.model and migrate internal/codegen to use it. google/dagger#2712
• Migrate Key to use DaggerType and DaggerAnnotation. google/dagger#2715

Current processor is javac + javaPoet, KSP I assume requires kotlin be the output language, what stance/path would be most likely here?

Drop java output support in favor of kotlin?
Take on the burden of supporting multiple processor api integrations and output languages?

Not seeing anything here on the topic nor any pending milestones. Perhaps this might be the start of the next milestone list?

[JakeWharton]

I don't think there's an urgency here, but we can consider supporting it long-term once it's stable and once Dagger has migrated.

[zsperske]

With KSP support in alpha with dagger, is it time to revisit this? Or better to wait until it's fully released? The dagger docs mention:

"KSP processors are not able to resolve types generated by other Javac/KAPT processors. Thus, if your project contains other processors that generate classes that need to interact with Dagger or Hilt, then those processors also need to be migrated to KSP"

If inflation inject falls in that category, support for KSP in this library would be a prerequisite to migrating dagger to KSP for those who use it.

[JakeWharton]

We have no plans to implement this. In fact, you can expect to see this library deprecated within 6 months and then archived a year or two after that.

If you still want to use this library with KSP, I would suggest pursuing it as a separate project.

[zsperske]

Understood, we will look into doing so. Out of curiosity, do you recommend any alternatives to this library? And I suppose it can't hurt to ask for any pointers you have may have on migrating this library to KSP.

[JakeWharton]

Only Compose UI. If you are still using views, and we are, this library is perfectly stable and works fine. In general we'd rather use the migration of Dagger to KSP to incentivize moving to Compose UI. But also, we generally have pretty clean layering such that our views are in separate modules from other types that use Dagger and so sticking to annotation processing for those isn't the worst thing in the world.

[JakeWharton]

Also I've never used KSP so can't really help there. Most of our dynamic, compile-time stuff nowadays requires full on Kotlin compiler plugins.