[Inf1mum]

Description

kotlin-spring with useBeanValidation (the default) puts @field:Valid on container properties (List, Set, Map) and on free-form kotlin.Any properties. Hibernate Validator 9.1 (shipped with Spring Boot 4.1) deprecated container-level @Valid and logs HV000271/HV000272 while building bean metadata. Because the bean metadata cache is backed by soft references, the warnings are not only logged at startup: they come back every time the metadata of a rarely used model is evicted and rebuilt, so production logs end up with a steady stream of them.

This PR applies to the Kotlin templates what the Java generators got in #24176 (issue #23614, released in 7.26.0):

• beanValidation.mustache no longer emits @field:Valid for containers. Cascading goes through the element type instead (List<@Valid T>, Set<@Valid T>), which the element annotation infrastructure added in [kotlin-spring] Bean Validation and custom annotations on collection element types #25592 already renders for arrays/sets; the deprecated duplicate on the container itself is gone.
• Map values now cascade through the type argument as well: Map<String, @Valid V> (the generator opts into useBeanValidationOnMapValueType()). This deliberately preserves cascading validation of map values, which the earlier attempt fix(kotlin-spring): skip @field:Valid on Map container properties (HV000271) #24027/fix(kotlin-spring): skip @field:Valid on Map container properties (HV000271) #24029 dropped along with the annotation, and which was the reason that PR was closed.
• Free-form type: object and {} properties (rendered as kotlin.Any) no longer get @field:Valid - there is nothing to cascade into (HV000272).
• Bean-typed properties keep @field:Valid, so cascading into a single $ref property is unchanged.

Since the Kotlin compiler only writes type-use annotations into bytecode when compiled with -Xemit-jvm-type-annotations, note that the generated Gradle and Maven builds already set this flag when useBeanValidation is enabled (added in #25592). If you compile the generated sources with your own build, keep setting that flag - without it, cascading into elements silently stops (same situation as the array/set element annotations introduced in #25592).

Generated output change

// before
data class Pet(
    @field:Valid
    @get:JsonProperty("items") val items: kotlin.collections.List<Item>? = null,

    @field:Valid
    @get:JsonProperty("customInfo") val customInfo: kotlin.Any? = null
)

// after
data class Pet(
    @get:JsonProperty("items") val items: kotlin.collections.List<@Valid Item>? = null,

    @get:JsonProperty("customInfo") val customInfo: kotlin.Any? = null
)

which matches the expected output from the issue.

Testing

• KotlinSpringServerCodegenTest: updated the collection element annotation tests for the new map value rendering, and added fieldValidOnlyOnBeanTypedProperties, which asserts @field:Valid is present on a $ref-typed property and absent on free-form object, {} and free-form map properties.
• mvn -pl modules/openapi-generator test: green (5756 tests, 0 failures).
• Regenerated all kotlin-spring samples with bin/generate-samples.sh bin/configs/kotlin-spring-*.yaml: 35 deprecated @field:Valid annotations removed across 34 model files, no other diff.
• Compiled the regenerated kotlin-springboot sample with Gradle and checked the compiled model with javap: the field carries javax.validation.Valid in RuntimeVisibleTypeAnnotations at TYPE_ARGUMENT(0), which is exactly what Hibernate Validator 9.x reads for cascading into elements, and which no longer logs HV000271.

PR checklist

• Read the contribution guidelines.
• Ran the sample generation scripts under ./bin/ to update the kotlin-spring Petstore samples so that CIs can verify the change.
• Filed the PR against the correct branch: master.

Fixes #25347

---

Summary by cubic

Fixes #25347. kotlin-spring no longer emits the deprecated container-level @field:Valid on List/Set/Map properties, which Hibernate Validator 9.1+ (Spring Boot 4.1) warns about with HV000271/HV000272. Cascading is preserved through element-type annotations instead (List<@Valid T>, Map<String, @Valid V>), and bean-typed properties keep @field:Valid.

Free-form object/{} properties rendered as kotlin.Any lose the annotation since there is nothing to cascade into. Map value cascading is preserved via the type argument, unlike the closed attempt #24029 which dropped it entirely.

Type-use annotations are only visible to Hibernate Validator when compiled with -Xemit-jvm-type-annotations; the generated Gradle/Maven builds already set this flag when useBeanValidation is enabled.

^{Written for commit ca40fce. Summary will update on new commits.}

[cubic-dev-ai]

2 issues found across 38 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator/src/test/java/org/openapitools/codegen/kotlin/spring/KotlinSpringServerCodegenTest.java">

<violation number="1" location="modules/openapi-generator/src/test/java/org/openapitools/codegen/kotlin/spring/KotlinSpringServerCodegenTest.java:8482">
P3: The comment claims exactly one `@field:Valid` remains, but this test never counts them. Either assert the count (e.g. with `countOccurrences`) or reword the comment to describe only the negative checks.</violation>
</file>

<file name="modules/openapi-generator/src/main/resources/kotlin-spring/beanValidation.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/kotlin-spring/beanValidation.mustache:2">
P2: The new `isAnyType` guard also matches inline `oneOf`/`anyOf`/`allOf` bean properties, so those properties lose `@field:Valid` and their nested constraints are no longer cascaded. Exclude only free-form/arbitrary `kotlin.Any` properties, or add a composed-model exception.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: The new isAnyType guard also matches inline oneOf/anyOf/allOf bean properties, so those properties lose @field:Valid and their nested constraints are no longer cascaded. Exclude only free-form/arbitrary kotlin.Any properties, or add a composed-model exception.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At modules/openapi-generator/src/main/resources/kotlin-spring/beanValidation.mustache, line 2:

<comment>The new `isAnyType` guard also matches inline `oneOf`/`anyOf`/`allOf` bean properties, so those properties lose `@field:Valid` and their nested constraints are no longer cascaded. Exclude only free-form/arbitrary `kotlin.Any` properties, or add a composed-model exception.</comment>

<file context>
@@ -1,4 +1,3 @@
-    @field:Valid{{/isDateTime}}{{/isUuid}}{{/isNumber}}{{/isPrimitiveType}}{{/isContainer}}
\ No newline at end of file
+{{! @field:Valid cascades only into bean-typed properties. Containers (List/Set/Map) cascade via element-type annotations instead (e.g. List<@Valid T>, Map<String, @Valid V>) - a container-level @Valid is deprecated by Hibernate Validator 9.1+ and logs HV000271, and free-form / Any-typed properties render as kotlin.Any with nothing to cascade into (HV000272). }}{{!
+}}{{^isContainer}}{{^isPrimitiveType}}{{^isNumber}}{{^isUuid}}{{^isDateTime}}{{^isFreeFormObject}}{{^isAnyType}}
+    @field:Valid{{/isAnyType}}{{/isFreeFormObject}}{{/isDateTime}}{{/isUuid}}{{/isNumber}}{{/isPrimitiveType}}{{/isContainer}}
\ No newline at end of file
</file context>

[cubic-dev-ai]

P3: The comment claims exactly one @field:Valid remains, but this test never counts them. Either assert the count (e.g. with countOccurrences) or reword the comment to describe only the negative checks.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At modules/openapi-generator/src/test/java/org/openapitools/codegen/kotlin/spring/KotlinSpringServerCodegenTest.java, line 8482:

<comment>The comment claims exactly one `@field:Valid` remains, but this test never counts them. Either assert the count (e.g. with `countOccurrences`) or reword the comment to describe only the negative checks.</comment>

<file context>
@@ -8455,10 +8455,36 @@ public void collectionItemsGetBeanValidationOnElementType() throws IOException {
+                "val anything: kotlin.Any? = null");
+        // free-form map values render as kotlin.Any without any @Valid
+        assertFileContains(holder, "val anyMap: kotlin.collections.Map<kotlin.String, kotlin.Any>? = null");
+        // exactly one @field:Valid remains (singlePet); containers and Any-typed fields carry none
+        assertFileNotContains(holder,
+                "@field:Valid\n    @Schema(description = \"\")\n    @param:JsonProperty(\"pets\")",
</file context>

Suggested change

	// exactly one @field:Valid remains (singlePet); containers and Any-typed fields carry none
	// containers and Any-typed fields carry no @field:Valid; singlePet keeps it (checked above)