[REQ] Java native - support both async and sync at the same time

[wtrocki]

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

[REQ] Java native should have option to use both sync and asyncNative generators at the same time. Currently asyncNative=true value would generate only async handlers

Describe alternatives you've considered

Generating both into 2 separate java packages / separate projects.

Additional context

[snago]

This was suggested by @wing328 in the PR that added asyncNative: https://github.com/OpenAPITools/openapi-generator/pull/4721#issuecomment-567387617

I would like to try to create a PR for this but I'm a bit unsure about how to handle backwards compatibility.

Ideally I would like to remove the asyncNative option and just always generate both sync and async operations (e.g. both addPet and addPetAsync), but that would be a breaking change for those that currently use asyncNative.

A backwards compatible way would be to keep the asyncNative option and make it mean "async only", i.e.:

• With asyncNative set to true, then addPet would be async.
• With asyncNative set to false, then we could generate both addPet and addPetAsync.

The backwards compatible way would make the mustache-templates much more complicated though.

@wing328 Do you have any opinions/guidance on how to go forward with this?

[wing328]

@snago have you tried the java client generator with the okhttp-gson library? it outputs Java SDKs with both sync and async method (and sync method simply calls the async method and wait for completion). Is that what you're looking for?

Ideally we should output the same in the native library.

[snago]

I looked at the output for okhttp-gson now and yes, that's similar to what I mean. For each operation I would like to have:

• {{operationId}}(...) - normal synchronous request
• {{operationId}}WithHttpInfo(...) - synchronous request with result wrapped in ApiResponse where response code and headers can be accessed
• {{operationId}}Async(...) - asynchronous request
• {{operationId}}WithHttpInfoAsync(...) - asynchronous request with result wrapped in ApiResponse where response code and headers can be accessed

I don't want to switch to okhttp-gson, I would like to keep using the java.net.http.HttpClient.

Currently I use the native library with a templateDirectory containing a modified api.mustache to get the above methods for each operationId. So I have a working generated native client that I use with both sync and async methods.

I would love to create a PR for this, but it would be a backwards-incompatible change.

• Remove (or ignore) the asyncNative option
• Always generate the above methods for each operationId

People that use asyncNative today would get compilation errors and would have to change their code to call fooAsync instead of foo.

Is that OK? Or should I do more work to make it a backwards compatible change?

[wing328]

my take is to create another library called "native-nextgen" with the breaking changes

and later we will do a swap

native => native-deprecated native-nextgen => native

that way users can fallback easily for easier, smoother migration.

we did this before for jersey2 and okhttp-gson to allow breaking changes with fallback by adding another library option.