Openapi-generator: [REQ] [Java] use a builder pattern for parameters?

[bgong-mdsol]

Is your feature request related to a problem? Please describe.

Not an issue per se, just a better way to achieve the same result.

Describe the solution you'd like

Currently parameters of an endpoint become parameters on a method.

Some endpoints have many parameters and as a result, the method will have 10s of parameters.
Something like:

search(uuid, uuid2, uuid3, name, some_bool, other_bool, this_int, this_other_uuuid, other_bool, name2, name3)

The problems are:

• Usually you only need a couple of params so you call this with 2 params and 9 null
• It is very difficult to review and very error prone
• If the openapi spec changes the order in which they write the params or if they add a param in the first position, all the params will shift position. If types match, the code will compile but the outgoing call would be totally different.

To mitigate that, we used a builder pattern in our own templates to handle parameters, usage roughly looks like that:

String operation = "unlock";
String operatorUuid = "596ad8ad-40f3-4fcd-b8af-7e7be5d8337c";
ServiceClient myApi = createServiceClient();

APIpermissionsIndexParams params = APIpermissionsIndexParams.builder()
  .operation(operation)
  .operatorUuid(operatorUuid)
  .build();

List<Permission> response = myApi.permissionsIndex(params);

Describe alternatives you've considered

Using Map<String, Object>.

Additional context

N/A

---

We would like to contribute the code back upstream but before opening a PR we'd like to hear the thoughts of the java tech committee.

Thanks!

@bbdouglas @sreeshas @jfiala @lukoyanov @cbornet @jeff9finger @karismann @Zomzog @lwlee2608 @bkabrda

[jeff9finger]

I would definitely like to see this. We have implemented our own builders for this purpose and to have them generated would be excellent.

I'd like to see the methods on server generated controller methods be able to not need to declare all the possible query parameters as well. I know that is a separate item, but very similar in concept.

[jfeltesse-mdsol]

As you recognize, I think the server-side of this should be implemented at a different time, through a separate PR.

As for the client side, should we keep the existing code in place (that generates methods with _n_ arguments) for backwards-compatibility or should we replace entirely and target 5.x?

[cbornet]

:+1 very good idea !

[jfeltesse-mdsol]

Heads up, we're going to tackle that soon for the native JDK 11 httpclient variant of the client templates.

One question still left unanswered though is:

As for the client side, should we keep the existing code in place (that generates methods with n arguments) for backwards-compatibility or should we replace entirely and target 5.x?

[wing328]

@jfeltesse-mdsol better have backward-compatibility via an option in this case.

[bgong-mdsol]

The pull request is ready for review.

[puneetgoyal08]

Hi, I tried using this but I was only able to generate it by selecting library as native, which made me use java version 11. Is there any way i can keep using java 8 and still use the builder pattern?

Thanks!

[wing328]

@puneetgoyal08 please try the jersey2 library option.