bumptech / glide

An image loading and caching library for Android focused on smooth scrolling
https://bumptech.github.io/glide/
Other
34.67k stars 6.12k forks source link

Feature request: Support KSP #4492

Closed davidjwiner closed 2 years ago

davidjwiner commented 3 years ago

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 commented 3 years ago

"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 commented 3 years ago

More social pressure!

sjudd commented 3 years ago

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: https://github.com/bumptech/glide/blob/a8c24c63c195306f82e36775d9f08f23c72c700e/annotation/compiler/src/main/java/com/bumptech/glide/annotation/compiler/ProcessorUtil.java#L57. 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 commented 3 years ago

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 commented 2 years ago

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

what does that mean?

anjalsaneen commented 2 years ago

Any updates on this?

ArtemKleinschmidt commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

mistletoe5215 commented 2 years ago

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 commented 2 years ago

Glide is blocking us from migrating from KAPT to KSP too

sjudd commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Dagger2 are very close to support ksp

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

mrmike commented 2 years ago

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 https://github.com/google/dagger/issues/2349

elomonaco commented 2 years ago

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 commented 2 years ago

One more vote for this

sjudd commented 2 years ago

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 commented 2 years ago

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