Add symbol processor for configuration metadata

[salatmaster]

This adds spring-boot-configuration-symbol-processor, a KSP processor that generates configuration metadata for Kotlin sources, as an alternative to running the annotation processor through kapt. It reuses the metadata model of the existing annotation processor, so the generated META-INF/spring-configuration-metadata.json is identical in format.

Besides removing the need for kapt, it fixes metadata that kapt currently loses. For a data class with Kotlin defaults:

@ConfigurationProperties("demo")
data class DemoProperties(val port: Int = 8080, val name: String = "demo")

kapt generates a stub with two constructors, the annotation processor can no longer deduce the bind constructor, and no properties end up in the metadata at all — only the group. The symbol processor describes both properties. KDoc on constructor parameters (@property) is picked up as well, which kapt drops.

Supported: constructor and JavaBean binding, @DefaultValue, @Name, nested groups, @NestedConfigurationProperty, @ConfigurationProperties on a method, actuator endpoints, deprecations, KDoc descriptions, merging of additional-spring-configuration-metadata.json, and @ConfigurationPropertiesSource.

Known limitations, all covered in the new appendix section:

• Default values declared with an initializer are invisible to KSP ([feature request] Retrieve property default value for compile time constants google/ksp#1868). kapt does not expose them either, so this is not a regression, and @DefaultValue still works.
• Additional metadata has to be located with a processor option, since KSP gives a processor no access to module resources.
• A module has to apply either this processor or the annotation processor, as both write the same file.
• Endpoint annotations are matched directly rather than through meta-annotations.

Tests drive the processor through the KSP2 API directly, so there is no third-party test dependency. The processor is compiled against symbol-processing-api 2.3.0 and declares it as compileOnly, so the KSP version stays under the user's control.

I'm aware this is marked as pending design work, so please treat it as a concrete proposal rather than a finished feature — happy to rework it if you'd rather see a different shape, such as an abstraction shared with the annotation processor.

See gh-28046

[wilkinsona]

Thanks for the proposal. Unfortunately, we're not happy with the approach taken here as it duplicates a considerable amount of logic between the Java annotation processor and the proposed KSP support. Ideally, any KSP support should be as thin a layer as possible that deals with Kotlin specifics before delegating to an implementation written in Java that's shared between the Java annotation processor and the KSP support. The issue is pending design work as we don't know exactly how to do that or if it's even feasible. If it proves not to be feasible it's unlikely that we'll support KSP as the maintenance burden will be too great.

[wilkinsona]

happy to rework it if you'd rather see a different shape, such as an abstraction shared with the annotation processor

Just noticed this after I'd made the previous comment.

This is exactly what we'd prefer to see. If you'd like to make an alternative proposal that takes this approach, or explore its feasibility and comment on the issue with your findings, that would be great.

[salatmaster]

Thanks for the feedback, @wilkinsona. I've explored the approach that you described and opened #51930 as an alternative proposal.

It introduces a small language-neutral model in spring-boot-configuration-processor and moves the logic of the annotation processor onto it, so that the annotation processor and the KSP support are two thin adapters over the same Java implementation. The KSP side no longer contains any metadata logic, and the metadata that the annotation processor generates for Spring Boot's own modules is unchanged. The details and what I'd like your opinion on are in the description of the new pull request.