@mosesonline
The changes was done in #15891 to "fix" #18080 (23 comments!)
So you ask to revert the behaviour. IMHO you're right.

The use of !required was intially introduced by @wing328 in #14961 to fix #14875 and #14833.

Maybe the main issue is with the handling of containerDefaultToNull that could have a wrong implementation for required collections.
As you say: "I could use the 'containerDefaultToNull' property, but than all collections are null, also the required"
See #14310

I have difficulties finding the "correct" implementation for required and nullable yes/no (not to mention openapiNullable and useOptional for the spring generator). Look for example at the crazy discussion in #14765 (47 comments!)
Finally it was implemented and merged in #17202. That produces unmaintanable mustache templates, multiple bugs and regressions (for example there are NullPointerExceptions when using optional in spring!)

It seems people agree to disagree.
To end the debate we could define a matrix defining the behaviour of nullable/required in the contracts + configOptions in the generator. And potentially adding new configOptions to satisfy everyone's opinion.

@mosesonline, what's the status of this fix? I saw that you created a PR, but that it had at least one failing suite. Is there a way that I or my team can help? This same issue is causing a downstream problem in the Java client. Thanks.

@mosesonline I understand your frustation.
I could work on that issue. But currently I have the feeling that several PR are not reviewed nor merged.
It's quite discouraging.

Thanks @jpfinne. I see that the project has a huge number of open PR's. Is there a way that I can help shepherd this one or encourage it to get attention? At least for the Java client, it is making current releases of the client unusable because the client generates empty content "{}" for fields that should be unset.

I could work on that issue. But currently I have the feeling that several PR are not reviewed nor merged.
It's quite discouraging.

@jpfinne sorry to hear that. if you can keep the PR small, definitely it will be much easier to review.

i know contributors like to have one (big) PRs with several enhancements/bug fixes to make their life easier but a PR changing several hundred files (including samples update) is just not easy to review/get it merged.

@rjeberhard if you can help review other PRs and ideally test these locally, that would be great (you can mark the PR as "approved" to draw our attentions).

Sorry, for being silent. I would be happy for any help to fix theis issue.

Hello @wing328 @mosesonline @jpfinne

This is again a breaking change. We cannot absorb these changes in minor versions.

Also, in my opinion it seems wrong. By default, nullable is false, so if you don't set that property, collections must be initialised.

The initial change to initialize the collections was also a breaking change. It broke our code.

The initial change to initialize the collections was also a breaking change. It broke our code.

The same thing happened to me...

But the solution I think is to add to the API nullable: true (remember that by default nullable is false).

What do you think?

Hi @martin-mfg, I noticed you received one approval for the PR addressing this issue. It’s likely to be merged soon? If there’s anything I can assist with, I’d be happy to help.

Hi @martin-mfg, I noticed you received one approval for the PR addressing this issue. It’s likely to be merged soon? If there’s anything I can assist with, I’d be happy to help.

Hi, I am waiting for @wing328 to merge the PR. I think there's nothing else to be done.

I believe there are conceptual issues with the current approach to handling default values.

Reference from Standards:

• OAS 3.0.1: "The default value represents what would be assumed by the consumer if a value is not provided."
• JSON Schema 2020-12: "This keyword can supply a default JSON value associated with a schema."
• Understanding JSON Schema: "default is used to express that if a value is missing, it is the same as if it was present with the default value."

Current Issues:

1. Defaults During Field Initialization:

   • Assigning default values during field initialization affects JSON serialization, which is not the intended purpose. Defaults should handle missing data during deserialization, not change serialization behavior.

2. Inconsistent Implicit Defaults:

   • Lists and maps are defaulted to empty collections, while strings are not (e.g., not set to empty strings). This inconsistency can cause confusion and unexpected behavior.

Suggestions for Improvement:

1. Avoid Implicit Defaults:

   • Ensure consistency by explicitly defining all defaults, with no implicit defaults for any type.

2. Remove containerDefaultToNull:

   • If no explicit default is defined, null should be used by default, removing the need for containerDefaultToNull and simplifying behavior.

3. Apply Defaults Only During JSON Deserialization:

   • Assign defaults only during deserialization using an all-args factory method annotated with @JsonCreator. This ensures defaulting is limited to deserialization and doesn't impact serialization.

@martin-mfg @jpfinne please can you check this comment?

Hi all,

Thanks for all the feedback, suggestions, PRs, etc.

I've been thinking about this more and more and I think we all agree ideally we need to solution that works in all generators instead of just Java-related generators.

I'll try to come up with something later this week or next so that you guys can try it out via a PR.

Best regards,
William

Hey guys, what's the status on this issue?

Looking forward to resolution of this. Thank you!

Has there been any progress or a decision made? I see this has gone a bit quiet 😿

Hi all,

Thanks for all the feedback, suggestions, PRs, etc.

I've been thinking about this more and more and I think we all agree ideally we need to solution that works in all generators instead of just Java-related generators.

I'll try to come up with something later this week or next so that you guys can try it out via a PR.

Best regards, William

Hi @wing328 , do you need some help in this? This is also blocking from our side, and there's no temporary workaround as we have thousands of specs, and many of them we don't own/we can't change. We have an openapi generator wrapper in which we'd like to rollback to the 7.4.0 behavior of initializing containers while using the 7.13.0 version.

sorry for the delay. too busy these days...

i just filed #21269 with instruction on how to test it

would be great it you test it with your use cases.

please reply to the PR with your test results.

thank you 🙏

Can others please help the PR #21269 when you've time?

Just merged #21269

Please give it a try with the snapshot version: https://oss.sonatype.org/content/repositories/snapshots/org/openapitools/openapi-generator-cli/7.14.0-SNAPSHOT/

and reply to the PR if you find any issues