Feature request: Support KSP

[davidjwiner]

For Kotlin projects, Glide 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 Glide 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.

[pvegh]

"The reduction of build times is only applicable if there are no other processors that use KAPT."
source: https://developer.android.com/jetpack/androidx/releases/room#2.3.0-beta02

Meaning: if you have Glide in your project, KSP won't bring any benefits until Glide support is ready.

They told us to exercise social pressure. Here it is :)

[joshschriever]

More social pressure!

[sjudd]

Unfortunately the API for KSP is not compatible with the java equivalent. We're going to have to do some non-trivial abstracting, mostly of the methods here:

glide/annotation/compiler/src/main/java/com/bumptech/glide/annotation/compiler/ProcessorUtil.java

Line 57 in a8c24c6

final class ProcessorUtil {

. The KSP team took a stab at this and was able to come up with a prototype, but wasn't able to make it production ready.

Since Glide is an open source project, anyone is welcome to contribute. The best way to apply social pressure is to of course spend your time on the improvement :)

This isn't completely straightforward, so if someone is interested, please reach out to me directly before you get too far so we can talk about it.

[sjudd]

Oh this also appears to be blocked internally due to lack of support where Glide is hosted, so we'll need more work from the KSP team before it's possible to submit anything here.

[eman1986]

Oh this also appears to be blocked internally due to lack of support where Glide is hosted,

what does that mean?

[anjalsaneen]

Any updates on this?

[ArtemKleinschmidt]

Happy new year 2022 everyone!
It's been almost a year since the last Glide update.
Any updates on the KSP support status?
It's the only dependency that blocks my project migration to KSP.

[mistletoe5215]

Happy new year 2022 everyone! It's been almost a year since the last Glide update. Any updates on the KSP support status? It's the only dependency that blocks my project migration to KSP.

me2

[Ezrael2k5]

Happy new year 2022 everyone! It's been almost a year since the last Glide update. Any updates on the KSP support status? It's the only dependency that blocks my project migration to KSP.

me2

me2

[bennyhuo]

Happy new year 2022 everyone! It's been almost a year since the last Glide update. Any updates on the KSP support status? It's the only dependency that blocks my project migration to KSP.

me2

me2

me2

[alvin96]

Happy new year 2022 everyone! It's been almost a year since the last Glide update. Any updates on the KSP support status? It's the only dependency that blocks my project migration to KSP.

me2

me2

me2

me2

[fertwo]

Hi guys, any updates on this?
It's the only dependency blocking our migration to KSP too :(

[mistletoe5215]

hi all,as u know, glide-parent project is a project based on java ,i've released a version of glide ksp jar which using kotlin language and ksp to maven central repository,named io.github.mistletoe5215:glide-ksp:1.0.0,any one interested can have a try.It can satisfied my own project's needs.However ,i still have one problem:can't find classes with GlideModule annotation in library or jar/aar dependcies ,therefore,i just wrote these class qualifiedNames in ksp options's arg,hope some master can help me @sjudd ..@A@,the following is my glide-ksp project
see link

[trevorhackman]

Glide is blocking us from migrating from KAPT to KSP too

[sjudd]

KSP apparently continues not to be available in the Google repo where Glide lives, which will complicate a migration. We could still accept contributions towards adding a second processor externally. It'll require some coordination, so please let me know if you're interested in working on it.

[techwn]

I found that Kotlin seems going to abandon KAPT in new K2 compiler: https://youtrack.jetbrains.com/issue/KT-52284

Change Log here: https://github.com/JetBrains/kotlin/releases/tag/v1.7.0-RC2

[ephemient]

Please be careful what information you spread. KAPT is currently not supported in the experimental K2. It is still on the roadmap for beta. https://youtrack.jetbrains.com/issue/KT-52604/Release-K2-Beta

[neworld]

Dagger2 are very close to support ksp

Very close? Please, could you share the source of this statement?

[mrmike]

Dagger2 are very close to support ksp

Very close? Please, could you share the source of this statement?

Looks like there is still quite a lot of work to do google/dagger#2349

[elomonaco]

they're at least closer than glide is, glide doesn't even seem to be trying, they just said it's not easy and asked for volunteers to help with it.

[kroussevrb]

One more vote for this

[sjudd]

Plan for now is to support:

1. AppGlideModules
2. LibraryGlideModules
3. Excluding LibraryGlideModules from an AppGlideModule.

We will not supported Glide's generated API (Extensions, GlideApp, GlideRequests, GlideRequest). We will not support modules registered via AndroidManifests.

This will allow people to use KSP to configure Glide and register integration libraries while substantially minimizing the amount of code that needs to be duplicated in the KSP processor. Users that want to use the full generated API can continue to use the Java annotation processor.

I'm not sure how many people today use GlideApp/GlideRequests/GlideRequest without an Extension today. We did recommend people do so for a while (and may still) in our documentation. If we don't generate those in KSP, people will have some migration work to do to use KSP. It's pretty trivial because the APIs will be identical, but a large codebase may have to change a lot of callsites to switch from the generated API back to the underlying classes (Glide, RequestManager, RequestBuilder). If a lot of you do this, please let me know here. We could consider trying to generate these classes to ease the migration path while still not supporting Extensions.

[sjudd]

Launched in 4.14.0 (though you'll want 4.14.2+)