[BUG][Java] Model does not compile due to fluent-setters conflicting with set_* field normal setter

[magicDGS]

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 trying to generate a default java client model for an API that I described (and where I have no control over the serialized model returned by it), the class generated for one schema contains duplicated methods and thus does not compile. The schema itself containing a name and a set_name fields. This results on 2 methods called setName, one being the builder-like setter for the set_name field and the other the setter for the name field.

I would like to know if this is something that can be fixed or there is already a workaround for this use-case. The only requirement is to be able to deserialize/serialize the object with the name and set_name field, so it doesn't matter if the way to do so is to change the field-name/methods on the generated class as a workaround.

openapi-generator version

6.3.0

OpenAPI declaration file content or url

• https://gist.github.com/magicDGS/98af9201ab588491fdc6a9d798e62713

Generation Details

• Generator: java
• Config: default
• Run with npx package

Steps to reproduce

1. Run on the command-line:

npx @openapitools/openapi-generator-cli generate -g java -i https://gist.githubusercontent.com/magicDGS/98af9201ab588491fdc6a9d798e62713/raw/39ae21c701334aa9b4fcb04dc32094314f81924d/openapi.yaml

2. Check the class org.openapitools.client.model.ConflictingSchema
3. Class does not compile due to the following methods:
   

Related issues/PRs

• [JAVA] Bug generating model when discrimator is "_type" and a property called "type" also present in response schema #9444 - similar problem, but without set on the prefix, but just _ (_typeandtype` conflicting).

Suggest a fix

The solution on the related issue won't work as only takes into account names starting with _.
As I am kind of new with OpenAPI and its generator, the only suggestion that I have is to provide a way to override the name of the field/getter/setter somehow for those kind of conflicting names, or adding some extension for providing it on the openapi spec.

If there is a generator and/or option of using a different library than GSON for the model serialization/deserialization, it is also a solution from my side, as I don't need to stick to a specific library.

[magicDGS]

Found that the builder pattern to the pojos was added on the template here: 54e78bd. Could be possible to add a flag to the tool to skip on the moustache template the builders (false by default) so at least I can use that workaround until a more consistent way to deal with the conflicting names is thought? If that's a possibility, I can try to contribute.

[magicDGS]

I was investigating a about the pattern that is causing the problem as I have never saw something like that in java, and it turns out that it is the fluent-setter pattern (see this article). This is similar to the builder pattern but within a POJO, and it is not an standard one as it is described in the article that advocates for it (see also some old discussion here), although there is an option on Lombok to generate such methods. Nevertheless, I believe that it should be either one or the other, an standard setter (e.g., public void setValue(String value)) vs a fluent-setter (public MyClass value(String value)) and not provide both on the generated POJOs.

So I would now suggest one of the following solutions for the problem:

1. A flag to disable the generation of fluent-setters default to false (backwards compatible). This will fix my problem but also does not allow to select one or the other, so I can imagine in the future some user wanting the fluent-setter but not the other one in a use-case like mine.
2. A flag to generate fluent vs. standard setters (breaking). This will require to change other templates too, as most likely the setters in used on other generated code might need one or the other. This is kind of future proof for different use cases, but more work.

I can propose a PR for (1) as I was investigating about the templates, identifying already several java-client generators where the pojo.moustache has the fluent-setters, and I can investigate also java-server templates cause I believe that the same problem arise there and I will use it in the future. For the second, I am not sure how much time it can take until I see all constellations of usages of the setter/getter and if it will be required to add to the java-code some custom property to be added to the template-engine so it uses the getter as expected, and thus I would prefer to leave that option if decided to developers with more familiarity on the code.

[t-beckmann]

I‘d opt for an option disabling the fluent setters only. That said, you can also pass a modified template when invoking the generator so that you can remove the offending fluent setters: https://openapi-generator.tech/docs/templating#retrieving-templates

[duracotton]

Push
The fluent setters are being generated in parallel to the standard generated setters. This might be confusing.
I would't mind having two variants existing but the thing is: The generated fluent setters are not using Bean validation annotations even if the generator option is enabled:
<configuration> <generatorName>spring</generatorName> ... <!-- Generator-specific config options --> <configOptions> <useBeanValidation>true</useBeanValidation> <performBeanValidation>true</performBeanValidation> </configOptions> </configuration>

So this might lead to usage of the wrong setters. This also might be a bug of the fluent setter generation.

[t-beckmann]

The fluent setters are being generated in parallel to the standard generated setters. This might be confusing.

You are indirectly referring to i.e. generating a builder inner class or so instead? Well, changing generation like that is a breaking change. Could open a separate issue for that..

The generated fluent setters are not using Bean validation annotations even if the generator option is enabled

Bean validation is relevant to the getters only. I believe it’s correct not having them on (fluent or not) setters.

[fjbeli]

I do not know what was the first reason to add these fluent setters (builder like setters) while you can generate builders by adding a config option generateBuilders to true. The fluent setters confuse also the serialization in jackson libraries, eg if by chance you have a property that is prefixed with set (eg. settlement) the fluent setter will drive the serialization that this as a normal java bean setter (even if the first letter after set is not capital letter). I understand that this is might be a bug in that lib but it drives me to wonder about having these fluent setter which are very useless and over engineer. Disabling these fluent setter would solve implicitly the issue.
This is the issue in jackson FasterXML/jackson-databind#2729.

[vlp]

Springdoc-openapi also misinterprets fluent setters for fields like settlement as ttlement field. Please add an option to disable fluent setters.