Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support KSP (Kotlin Symbol Processing) #1075

Open
natanfudge opened this issue May 6, 2022 · 8 comments
Open

Support KSP (Kotlin Symbol Processing) #1075

natanfudge opened this issue May 6, 2022 · 8 comments
Labels
enhancement New feature or request

Comments

@natanfudge
Copy link

Currently ObjectBox supports using KAPT for processing annotations in Kotlin.
KSP is a new Kotlin annotation processing framework by Google and supported by Jetbrains that processes annotations in a far more 'native' way than KAPT, resulting in improved performance and an API more suited for Kotlin. Consequently, KAPT has lost its focus from the Kotlin team (source).
ObjectBox should seriously consider providing an implementation for processing annotations in Kotlin using KSP. For reference, see this recent build time analysis:
image
A whopping 75.8% (24.2 seconds) of build time is spent on generating KAPT stubs, which supposedly KSP avoids completely. On the other hand, it appears only 0.8 seconds is spent doing actual Objectbox work.

Further reading:
What is KSP?
Why KSP?
KSP Github

@natanfudge natanfudge added the enhancement New feature or request label May 6, 2022
@greenrobot-team
Copy link
Member

Thanks for reporting! Funny enough, I stumbled upon the note regarding KSP while looking up some Kapt info and created an internal issue for this.

From a first look the main issue is that ObjectBox supports plain Java projects, so we likely would have to maintain two annotation processors.

@natanfudge
Copy link
Author

natanfudge commented May 10, 2022

@greenrobot-team Since that does seem like a big issue, I've done some research on it.
This very detailed article explains how Room (very similar to ObjectBox!) implemented KSP support while preserving Java support. They did it by implementing an abstraction layer called X-Processing that allows processing using KSP and JavaAP with a unified API, making the new code in Room itself be no less complex/long than the pure JavaAP equivalent, and even be simpler in some cases. Following this, Dagger, and Airbnb's Paris and DeeplinkDispatch have used Processing-X to provide their own KSP support, and contributed the things that they needed as well.
Processing-X (now known as room-compiler-processing) is available on Google's Maven, but is not considered an official library.

@greenrobot
Copy link
Member

@natanfudge Thanks for providing all the useful information here. ❤️ Could you also indicate some rough numbers on your project's size, so we can relate the build time to it?

@natanfudge
Copy link
Author

greenrobot It is a new project, so quite small. ~15 Kotlin files with an average of around 100 LOC.
By the way, is the annotation processor closed source? I can't find the source anywhere, even the source jar is empty.

@woniu163
Copy link

The current android jetpack platform actively embraces kotlin, kotlin has a more positive attitude towards ksp, and many android libraries are compatible with ksp, so ObjectBox supporting ksp is a very correct decision

@andrew-ld
Copy link

@greenrobot-team with kotlin 2 kapt slow down too much the compilation time, can prioritize the switch from kapt to ksp, now as workaround i added objectbox classes as a gradle submodule so the compilation is fast because kapt should process only few small files

@AlbertoSaezVela
Copy link

Any update about this feature? If is it in progress or any stimated release date or version?

@greenrobot-team
Copy link
Member

We'll share updates once there are some. In the meantime, it helps us more if you thumbs up the first post (GitHub can sort issues by thumbs ups)!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants