[BUG] [JAVA] 7.3.0 adds @lombok.NonNull on all required fields when any lombok annotation is included

[Squeeeez]

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

#17622 adds more lombok support, which is great!
As soon as any lombok annotation is included, every required field on the models now gets annotated with @lombok.NonNull
which adds a null check where none was present before (i.e. with 7.2.0) when using for example a lombok constructor or builder.

As such a breaking change which suddenly starts throwing NullPointerExceptions where none were thrown before it would be nice to have a way to configure such behaviour.

openapi-generator version

7.3.0-SNAPSHOT

OpenAPI declaration file content or url

The yaml configuration
The generated sample

Generation Details

bin/config-generate-samples.sh bin/configs/spring-boot-lombok-tostring.yaml

Steps to reproduce

Include any lombok class in additionalModelTypeAnnotation, mark a model attribute as required

Suggest a fix

I would suggest the use of a configuration possibility similar to useBeanValidation, either to disable @lombok.NonNull, or to choose which library is used for such Nullable/NonNull annotations. What are your thoughts?

[jpfinne]

@Squeeeez

The lombok generation has many issues: see #17793

What is your use case of @lombok annotations in generated code?
What do you miss from the non @lombok code?
Just AllArgArguments constructor and builder or something else?
AllArgAguments and builder can be generated in plain mustache and java code (I can create a PR)

I ask because pojo.mustache becomes too complex. I would like to delombok it.
Just adding a no arg constructor becomes tricky with all the combinations.

[vzorge]

@jpfinne Most people I know use it for the Builder.

In tests this is better to understand:

val someFoo = Foo.builder()
        .somefield("something")
        .bar(Bar.builder()
               .someBarField("barField")
        .build()

Then

val someBar = new someBar();
someBar.setSomeBarField("barField");
val someFoo = new Foo();
foo.setBar(someBar);
foo.setSomeField("someField");

Especially when the objects are quite large with lots of nesting.

But it seems like there are already nice "fluent" setters, so people should just use those.