[Java] Generate overloaded methods to support backward compatibility with optional parameters

[ataylormays-duetto]

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

If the server adds an optional parameter, that is a backward compatible and non-breaking change. However, when the client pulls in the latest spec and generates code, the optional parameter is added as an argument to the pre-existing method which breaks the client-side code. If the API change is non-breaking, client code should not break.

Describe the solution you'd like

If the codegen was updated to generate overloaded methods, client code would not break. Suppose for example the client was previously bound to an API with no parameters, and the client code was api.getData(). If overloaded methods are generated and an optional parameter was added, the client should would have the choice of continuing to call api.getData() (which would maintain existing behavior) or api.getData(newParam).

Describe alternatives you've considered

Adding a config option like useOptionals to cause the codegen to wrap optional params in an Optional<> would also be an improvement as the method signature is clear, but would still cause a breaking change in clients.

[jpfinne]

Overloaded methods work, but it is will be a nightmare with multiple string arguments. It might fail at runtime if the order of arguments changes, for example when adding a new required parameter

It is better to use the useSingleRequestParameter option available for some java clients (see https://openapi-generator.tech/docs/generators/java/) or form exploded query parameters as object (see https://swagger.io/docs/specification/serialization/#query)

Both options use an object for the query parameters. so new optional parameters have no impact as they will be nullable attributes in the query object.