Feature request: Support KSP

[davidjwiner]

For Kotlin projects, Dagger currently makes use of KAPT. This is generally quite slow since it requires generating Java stubs before the annotation processing step.

KSP offers an alternative to this by making it easier for annotation processors like Dagger to more directly use Kotlin's compiler plugin infrastructure. Based on initial benchmarks, using KSP can speed up build times by as much as 2x.

[Chang-Eric]

Just updating this to give a sense of where we are at. This is a priority for us that we are looking into. There are some complications though mostly due to the SPI plugins which expose the JSR-269 APIs through our public interface. There’s also the fact that our annotation processor code base is huge.

Because we still need to support our javac users, we cannot switch entirely to the KSP APIs which leaves us in a bit of a pickle since the places these are exposed are deep in our core model classes. I don’t think there is a possible way to get around this being a breaking API change, but we’ll need to figure out the right API to switch to that can support both KSP and javac SPI users.

Anyway, all this is to say, this is a high priority and we are working on this, but it is also a complicated thing to rollout for a codebase our size.

[ZacSweers]

Can you use compiler-processing from Room to simultaneously support both? SPI users can, for now at least, be told they're unsupported in KSP (which seems fair considering the SPI API is javac-based anyway).

[Chang-Eric]

Thanks for the pointer, we are already in discussion with that team about that as a possibility =)

[CoreFloDev]

Hi any update on this? Thanks!

[Chang-Eric]

Still working on it. We're preparing a new model that will wrap both javac and KSP types like in this recent change: 30fa0f3

[Jeffset]

SPI users can, for now at least, be told they're unsupported in KSP

I've opened a separate issue #2802 for that to track status and discuss possible solutions as my team is concerned about KSP support in SPI.

[bcorso]

@Jeffset, once we're ready to support KSP in Dagger, we will likewise support KSP in the SPI plugins as well. I think we can probably close #2802 , as this issue should track both.

Just to give you more details on our plans for the SPI plugin:

The new SPI model currently exists, and we are beginning to use it internally in Dagger. However, it is not yet available for users to write their own plugins.

The new model will be a thin wrapper around the javac/ksp types. For example, DaggerElement is a wrapper around Element in javac and KSDeclaration in KSP. If you need access to the javac or KSP types directly in your plugin, you will be able to call .compiler() to get which environment you're currently in (i.e. javac or KSP), and then call .javac() or .ksp() respectively to get access to the types.

Feel free to let us know if you have any concerns.

[ColtonIdle]

KSP is officially 1.0!
https://android-developers.googleblog.com/2021/09/accelerated-kotlin-build-times-with.html

My last dep that uses kapt is dagger + hilt! Do we have any estimated timeline? Just curious if this is a "likely by the end of 2021" type of feature request, or a "likely by the end of 2022" type of feature request. 😅

[ZacSweers]

Dagger maintainers are pretty good about posting updates, let's trust a push system rather than nagging about something they are obviously aware of and working on.

[Chang-Eric]

Updating here since it has been some time. We've been making progress on the KSP migration, which includes making changes to Room's xprocessing libraries which we are using. Things were recently delayed for a while as the migration uncovered and exacerbated an existing issue which is the main change of the 2.41 release we just did. This issue caused a large delay not only in pulling people off the migration but also because we were afraid of making the problem worse by continuing the migration.

For that reason, it is still hard to give any sort of estimate as it is really the unknowns that we're going to hit that will take the bulk of the time. Just that one issue discovered set us back a couple months. With that said, now that the 2.41 release is finally out, we are now unblocked to continue the migration work.

[recoverrelax]

any news here?

[osipxd]

Just click this button

[shaddyz]

any update on the progress?

[byates-fleetian]

KSP support is something my team urgently needs. To the point that we are considering finding a solution other than dagger.

[OussamaHaff]

@byates-fleetian, please take a look at @ZacSweers’s blog post to help keep the discussion about the actual content of the feature rather than trying to put pressure on the maintainers 🙏
(I’m not a maintainer/contributer)

https://www.zacsweers.dev/you-are-not-blocked/

[TWiStErRob]

Considering the number of votes on this, which I would put around 4-500, a better question might be:
Is there any way we (the community) can help?

[kles4enko]

@TWiStErRob As usual in the OSS community – PRs are welcome ;)

[bcorso]

Quick Update:

We’ve recently wrapped up the bulk of our migration to XProcessing -- a library that abstracts away the Javac APIs to allow Dagger’s processor to run in both Javac and KSP environments (see commits here).

However, along the way, there was a number of places in our codebase where we had to fall back to using Javac when there was no XProcessing equivalent. Thus, we’re now working with the XProcessing team to add support for these missing features.

Unfortunately, it’s unlikely that contributing PRs will help much in this phase of the project. The bulk of the work will be dedicated to designing the APIs, so any PRs would just shift our time from designing APIs to reviewing designs for APIs. In addition, this will require some level of coordination between the XProcessing and Dagger codebases, which will be easier to coordinate from our side.

However, once the bulk of that work is done, we will need some help testing with real projects using KSP, so we’ll definitely let you all know once we get there.

[mslalith]

it's been a long time since last update. Any planned ETA?

[functionobject]

This is quite a blocker for compose. To use 1.3.0 I need Kotlin 1.7, but that removes kapt. I'm sure I can't be the only one. Is a resolution of this issue close?

[shenguojun]

Waiting for the good news, our team will move to KSP once Dagger is supported.

[nickdonnelly]

Any news here?

[ColtonIdle]

It's here!

https://github.com/google/dagger/releases/tag/dagger-2.48

[bcorso]

Hi all, Dagger 2.48 includes the alpha release of the Dagger and Hilt KSP processors. Please see the release notes for more details.

Also, as an update on https://github.com/google/dagger/issues/2349#issuecomment-1549890357,  the @JvmSuppressWildcards and @JvmWildcard annotations will still be needed in your Kotlin sources until the second part of that change is completed. Currently, we have only implemented the first part of the proposed change (i.e. we’ve banned providing a binding with the same invariant type), as that was required for the KSP release.
Unfortunately, we had to put the second part of that change on hold as it was not needed for the KSP release, and it will likely take a good amount of time to address some of the unexpected issues we ran into while trying to implement it.

[FunkyMuse]

Hi all, Dagger 2.48 includes the alpha release of the Dagger and Hilt KSP processors. Please see the release notes for more details.

Also, as an update on https://github.com/google/dagger/issues/2349#issuecomment-1549890357, the @JvmSuppressWildcards and @JvmWildcard annotations will still be needed in your Kotlin sources until the second part of that change is completed. Currently, we have only implemented the first part of the proposed change (i.e. we’ve banned providing a binding with the same invariant type), as that was required for the KSP release. Unfortunately, we had to put the second part of that change on hold as it was not needed for the KSP release, and it will likely take a good amount of time to address some of the unexpected issues we ran into while trying to implement it.

Thanks for the alpha release, great job.

Does it mean that the "2nd part" is gonna generate Kotlin instead of Java code?

[bcorso]

@FunkyMuse, for the "2nd part" I mean this:

"Next, we’ll introduce another flag [...] that allows users to request a binding via any of its type’s variances, e.g. injecting @Inject Foo<Bar> or @Inject Foo<? extends Bar> would both be allowed (assuming the provided type can be assignable to them)."

Ideally, the implementation of that feature would not require generating Kotlin source, but admittedly that is part of what makes it difficult. Fwiw, I know generating Kotlin source is of some interest due to KMP; however, just to be upfront, it's not something we are currently working on at the moment.

[Hiraev]

Is KSP support still in alpha?

[bcorso]

The KSP story is kind of complicated.

KSP1 is deprecated. The reason why Dagger's KSP1 support remained in alpha was to address some performance concerns that we found when rolling out KSP within Google. However it's unlikely that those issues will be fixed now that KSP1 is deprecated.

As for KSP2, Dagger plans to support it but there's a number of known correctness issues that still prevent us from trying it out within Google. We're currently working with the KSP team to address those issues, but it will likely be a few months. Even after those correctness issues are fixed we will still need to see if there are any remaining performance issues before moving it out of alpha.

[mslalith]

If you are trying other DI libraries, try kotlin-inject. It's similar to Dagger

[cgruber]

@bcorso - any progress on this?

[bcorso]

@bcorso - any progress on this?

So far, we've only tested KSP2 with a small subset of Dagger targets within Google, but there's been some progress the last few months (see KSP fixes and XProcessing fixes), and all of the known issues for those targets have been fixed.

The KSP2 fixes should be available in the next KSP release (2.1.10-1.0.32).

Users are free to try out KSP2 whenever they want; however, before we claim KSP2 is "officially" supported in Dagger, we still need to 1) increase our test coverage by enabling KSP2 for all relevant Dagger targets within Google, then 2) go through the same process with Hilt. However, I'm hoping we've caught most of the main issues and the remaining work will be finding the edge cases.