The problem: Currently, ConfigurationProcessor is backed by Annotation Processing. In Kotlin annotation processors can be used thanks to KAPT. Sadly KAPT does not work with JDK 16+ ( https://youtrack.jetbrains.com/issue/KT-45545 ). For Kotlin there are other processors like KSP ( https://github.com/google/ksp ), yet they do not rely on Java Annotation processing.
Proposed solution: Provide an abstraction layer on ConfigurationMetadataAnnotationProcessor that will allow plugging in other processors. Additionally provide an adapter for KSP.
@sdeleuze
Comment From: wilkinsona
Thanks for raising this.
Sadly KAPT does not work with JDK 16+ ( https://youtrack.jetbrains.com/issue/KT-45545).
My reading of that Kotlin issue is that KAPT does work with JDK 16+, but that it requires adding some JVM arguments to open up some of the JVM's internals to KAPT. Have I misunderstood the discussion?
Comment From: kkocel
@wilkinsona You understood it better than I :) Yes, it's possible to break javac encapsulation using add-opens flags, but ihmo it's temporary (this flag can be taken away as with --illegal-access=permit in JDK 17).
I know that adding an abstraction layer over processors can add in additional complexity, but it can also be a safer solution (also please note that KSP authors claim that it's up to 2x faster than java annotation processors).
As with everything you should weigh your options as Spring maintainers.
Comment From: wilkinsona
The underlying problem with KAPT has now been fixed and will be part of the Kotlin 1.6 release. Rather than supporting a third-party alternative which, to me at least, has an unclear relationship with Kotlin and JetBrains, I think we should focus our efforts on working via KAPT. Thanks anyway for the suggestion.
Comment From: bespaltovyj
Hi, @wilkinsona.
The new Kotlin documentation says that kapt is in maintenance mode and new features are not planned.
And recommend using ksp(it should work faster).
ksp support.
Comment From: kkocel
@wilkinsona I asked about the relation of KSP and Kotlin: https://twitter.com/relizarov/status/1455452359669264384
So it looks like KSP is the way to go for Kotlin.
Comment From: stillya
Any updates? Kapt is horrible annotation processor, it will be great if spring will support ksp. I have all my backend on kotlin and I have to use Kapt and main problem is not even speed(but it's slow), kapt shadows errors constantly, invalidate build cache.
Comment From: hnljp
Just for your information. Google has created this abstraction layer over JavaAP and KSP. https://github.com/androidx/androidx/tree/androidx-main/room/room-compiler-processing https://mvnrepository.com/artifact/androidx.room/room-compiler-processing It was originally created for room, but they are now using it for different projects.
Comment From: snv
When trying to update to Java 21, i run into an IllegalAccessError again
java.lang.IllegalAccessError: superclass access check failed: class org.jetbrains.kotlin.kapt3.base.javac.KaptJavaCompiler (in unnamed module @0x59db8216) cannot access class com.sun.tools.javac.main.JavaCompiler (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.main to unnamed module @0x59db8216
Since kapt keeps breaking every now and then, it would be really great if spring moved away from using it.
Comment From: alwyn
I have been trying to use the usual workarounds on 21 with no success. If anyone has it working, please let me know.
Comment From: ajgassner
I have been trying to use the usual workarounds on 21 with no success. If anyone has it working, please let me know.
The fix will be backported to Kotlin 1.9.21, see https://youtrack.jetbrains.com/issue/KT-60507 In the meantime you have to use JDK 20 or 17 LTS, you decide.
Comment From: AlexeyTsvetkov
Slightly offtopic: there is a chance you don't actually need the configuration annotation processor at all. If you use Intellij IDEA Ultimate (I don't think that Community ever supported Spring configuration code insight), starting from 2023.2 Intellij does not rely on the metadata generated by the Spring boot configuration annotation processor. Other IDEs still might require it. I want to share this, because I was completely unaware of this until today (despite working at JetBrains), and removing KAPT improved our clean build times by 36%, incremental build times by up to 50%.
Comment From: deejay1
@AlexeyTsvetkov this still leaves the topic of the autoconfigure processor
Comment From: AlexeyTsvetkov
@deejay1 oh, I did not know about the autoconfigure processor. Still, the info above could be useful for those who only use the ConfigurationMetadataAnnotationProcessor (org.springframework.boot:spring-boot-configuration-processor artifact).
Comment From: m4rtin195
I'd like to vote for some attention to this, it's already 3+ years since KAPT was deprecated. It's annoying to rely on this old, slow and error-prone processor.
Comment From: natalie-zamani
Also curious when we might expect to see support for KSP.
Comment From: jeffawx
I don't even think I can get configuration processor + KAPT working perfectly, it works to some extent but when I started to put nested config class and default values, didn't see what I expect.
Comment From: mymx2
I try to write a ksp version mica-auto, then i found ConfigurationProcessor not support ksp yet.
I like Kotlin, but I hate when things become complex.
The Burden of Knowledge: Seeking Simplicity in Coding
The landscape keeps expanding: annotationProcessor, kapt, KSP, KSP2... learn Java Annotation Processing, then Kotlin Symbol Processing. With every new tool aiming to improve development, things grow more complex. We just want to code enjoyably, yet ironically, to code better, we end up learning more and more. When will we reach that sweet spot where less truly becomes more?
If Kotlin demands more from developers, should we just stick with Java then?
for now? i keep use kapt until i give up kotlin