[BUG] [JAVA] [JAXRS-SPEC] jarxrs-spec generators adds @Valid annotation to standard java types / enums

[anatoliy-balakirev]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

When using openapi-generator-maven-plugin with jaxrs-spec generator and enabled bean validation, the plugin generates @Valid annotation for all properties. @Valid annotation is only needed for objects, where the cascading validation is required. For standard Java types and enums it is useless. Moreover, when those annotations are there for those types - Hibernate Validator's performance degrades significantly (see: https://hibernate.atlassian.net/browse/HV-1928 and https://hibernate.atlassian.net/browse/HV-1933). I've checked other available generators and it looks like spring generates those annotations properly.

openapi-generator version

6.2.1. This is not a regression.

OpenAPI declaration file content or url

https://github.com/anatoliy-balakirev/openapi_generator_jaxrs_spec_validation_issue/blob/main/src/main/resources/models.yaml

Generation Details

See here:
https://github.com/anatoliy-balakirev/openapi_generator_jaxrs_spec_validation_issue/blob/main/pom.xml#L39-L62
And here:
https://github.com/anatoliy-balakirev/openapi_generator_jaxrs_spec_validation_issue/blob/main/pom.xml#L74-L86

Steps to reproduce

• Checkout the project from here: https://github.com/anatoliy-balakirev/openapi_generator_jaxrs_spec_validation_issue
• Run ./mvnw clean install on Linux or ./mvnw.cmd clean install on Windows (make sure JAVA_HOME is set to Java 17)
• Open targe/generated-sources/openapi/src/gen/java/com/example/demo/ folder to see the generated models, showing the issue
• Open targe/generated-sources/openapi/src/gen/java/com/example/demo_fixed/ folder to see the generated models, showing the suggested fix (using overridden templates from here: https://github.com/anatoliy-balakirev/openapi_generator_jaxrs_spec_validation_issue/tree/main/src/main/resources/templates)
• Open targe/generated-sources/openapi/src/main/java/com/example/demo/ folder to see the models, generated using spring generator

Related issues/PRs

Suggest a fix

Use beanValidation.mustache and pojo.mustache from the spring generator in the jaxrs-spec one.

[anatoliy-balakirev]

Created PR here: #14435

[mati199oo]

Hi, while I was working on a project in my job, I also encountered this problem. Probably because this project has big requests with hundreds of objects in a list, that are pretty complex. In normal projects with a simple requests we didn't have to check on the performance.

I noticed that it generates @Valid on a standard java objects, for example enum, BigDecimal, UUID. Also I saw that it generates @Valid twice - for the field, and for the getter to that field. I am not sure if it should generate it on a getter, since I thought that if I get some request, I won't change anything in there, I only want to parse to my model, and validate, so that I can safely read the data.

When I copied the generated objects into the source code, and then removed some of those @Valid annotations, it reduced the processing time from around 6500ms to 440ms on average.

But I am using spring generator that you wrote that works better, and still having those problems.
Do you think that your changes will also work with spring generator?

[anatoliy-balakirev]

Hi @mati199oo. My changes here are basically taken from the spring generator... Moreover, as there were no replies here, I've switched to the spring generator in the meanwhile and all our performance problems are gone now. So, if you are on the spring generator and you still have some performance issues - they must be coming from somewhere else, I would say.