Add constructor with required parameter for Spring

[alucas]

Fix #9789

Add constructor with required parameter for Spring

@cachescrubber @welshm @MelleD @atextor @manedev79 @javisst @borsch @banlevente @Zomzog

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: 🚨 ./bin/generate-samples.sh update a lot .py / .rb / .rs that have nothing to do with this PR, I dit not include them

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  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*.
  For Windows users, please run the script in Git BASH.
• In case you are adding a new generator, run the following additional script : 🚨 The script name is ./bin/utils/ensure-up-to-date(without .sh), this template is outdated

  ./bin/utils/ensure-up-to-date.sh
  

  Commit all changed files.
• File the PR against the correct branch: master (6.3.0) (minor release - breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks) 🚨 The next version is 6.5.0 right ? This template is outdated.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[welshm]

Thanks for the PR!

Just some minor suggestions

[welshm]

Can you make some of these nullable to excercise the nullability check as well?

[alucas]

I added a nullable & required parameter 🙂

[borsch]

@alucas thanks for the PR. Unfortunately there is a big think which block us from this being implemented earlier - inheritance. Currently your changes will work perfectly fine until you have inheritance in your models, so if you really want this to be merged you have to do you changes with this in mind

[alucas]

@alucas thanks for the PR. Unfortunately there is a big think which block us from this being implemented earlier - inheritance. Currently your changes will work perfectly fine until you have inheritance in your models, so if you really want this to be merged you have to do you changes with this in mind

@borsch isn't inheritance implemented with ‘allOf:‘ ? Because I have such case in my tests. Are you thinking of something else ?

[borsch]

@alucas you can check generated sample from configuration bin/config/spring-boot-delegate-j8.yaml there is generated model Cat extends Animal

[alucas]

@borsch Thx for pointing that problem, the generate code didn't even compile. I think I fixed it. We should probably add the execution of those generated tests in the CI ?

[borsch]

@alucas I found that there was one issue related to code generation due to which your custom test was running against incorrect classes. I've fixed this

Once all pipelines would be completed I'll merge this PR
Thanks for contribution

[welshm]

👏 Thank you for adding these tests! Merci beaucoup pour le addition!

[OlliL]

Marking the default Constructor deprecated is not a good thing to do imho. A POJO requires a default constructor. Otherwise most if not all those mapping frameworks out there won't work. So there is no point in marking it deprecated. It just polutes the code with unnecessary warnings. The constructor with only required parameters adds no benefit as there is for example no null check in it - so it gives you the impression to make things safer but it just does not. With a default constructor available and a constructor with required parameters but without null checks in it no "is required" is enforced. Removing the default constructor would break the Pojo spec so it will never be gone anyway.... so please remove that pointless deprecated annotation....

[alucas]

Hello,

You're right, there is no plan to remove the default constructor, that would be breaking.

Can you give us some example of warnings poluting your code ? Are they from the mapping framework ?

Note that you can disable this feature with the generatedConstructorWithRequiredArgs config

[borsch]

@alucas I believe it's just Java compiler warnings saying that you use deprecated API(deprecated constructor)

[OlliL]

yeah - its static code analysis tools like Sonar which start complaining for using those deprecated constructors. Yes, the warning could be turned of, or the code could be changed but as I tried to explain the new constructor does not add that much safety imho so i don't see that much of a point to change all the affected code just to get rid of the deprecation warning.

Thanks for letting me know about the config switch. I could have checked the documentation first 😄

[MelleD]

Don’t understand why Sonar should check generated code.

And off course this constructor add more safety and increase the readability also for client side code, because then you know what is mandatory and what not. That’s a old best practice to add mandatory fields into the constructor