[JavaSpring][21200] improve Kotlin interopability with optional values

[ondrej-simon]

nullable annotations are now added to getters, setters, parameters, for optional attributes without default value

Fixes #21200

For objects, Kotlin interopability works by inferring nullability annotations from getters and setters. Having Nullable annotation only on a member variable is not enough for Kotlin to know a property is nullable. This PR improves on this.

This PR also fixes problem where optional parameters without default values (e.g. headers, query parameters, cookies, request body) are not marked with nullable annotation, acting as if they were always present even when it is not the case.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@cachescrubber (2022/02) @welshm (2022/02) @MelleD (2022/02) @atextor (2022/02) @manedev79 (2022/02) @javisst (2022/02) @borsch (2022/02) @banlevente (2022/02) @Zomzog (2022/09) @martin-mfg (2023/08)

[ondrej-simon]

The pathParams.mustache file is intentionally left unaffected, because path params must always be required as per OAS and thus should/must never be null.

[MelleD]

FYI

"The release of Spring Framework 7.0 is scheduled for November 2025."

After that release this PR is outdatet because Nullable is deprecated, because spring is using JSpecify
https://spring.io/blog/2025/03/10/null-safety-in-spring-apps-with-jspecify-and-null-away

spring-projects/spring-framework#28797

[ondrej-simon]

@MelleD , I do not think migration to JSpecify (although welcome) should be a part of this PR, which merely improves existing concepts without introducing breaking change in this generator. I assume nullability annotation migration, including specification of NullMarked package info, will be a topic on its own.

I was actually considering the migration, but that would be too risky in order to just improve Kotlin interopability, which was my main goal of this improvement.

[MelleD]

My point is, if you know this change will be deprecated in five months, do you want really to introduce it?

I find it odd to introduce something knowing it will soon be deprecated.
From Spring Team:
"So the new plan is to leverage directly JSpecify annotations and deprecate Spring Framework null-safety annotations."

[ondrej-simon]

I admit, this improvement is influenced by me benefiting from it directly. The absence of these annotations as of now is a blocker at the company I work for when it comes to Kotlin adoption. So this would greatly help us in terms of the Kotlin adoption, and perhaps be beneficial to others, too.

I do not know what the roadmap for JSpecify adoption is for OpenApi Generator. Maybe @wing328 could shed some light on that? If there is a plan to adopt JSpecify e.g. within a month, I have no problem waiting for the final solution. But if the target is 6+ months, not having to wait and improve the code related to not only Kotlin interopability but in general, is IMO still a step in the right direction.

Final note, the improvement I am promoting here would not magically appear just by switching to JSpecify. Someone would still need to fix the templates I fixed here (because the code is in fact not being generated correctly - e.g. getters are missing the Nullable annotation for return types). If this project simply moves from Spring nullability annotations while forgetting about these gaps, the problems would still remain, and it does not matter whether Spring or JSpecify nullable annotations are used.