fix #17419 useOneOfInterfaces option for java clients & servers

[Nicklas2751]

Some java generators generated wrong, not compiling code, when using the option useOneOfInterfaces.
The bug was caused by old/wrong model.mustachefiles without the part supporting the useOneOfInterfaces option.
These clients were affected:

• jersey2
• jersey3
• microprofile
• native
• okhttp-gson

as well as the following servers:

• helidon
• jaxrs
• mirconaut
• microprofile
• play
• pkmst

This PR fixes all of them 😎

It also fixes a compile error of the java native client generator when using anyOf with generic types.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04) @lwlee2608 (2019/10) @martin-mfg (2023/08)

[Nicklas2751]

@wing328 Seems like the others don't have any feedback on this 😅

[martin-mfg]

Hi @Nicklas2751, thanks for the PR! I found 2 problems:

• When I run OpenAPI Generator with generator=java, library=okhttp-gson, additionalProperties:useOneOfInterfaces=true on this input spec, the output fails to compile because org.openapitools.client.model.TestResponse.CustomTypeAdapterFactory doesn't exist.
• Using library=jersey2 with all other settings like above generates a file docs/TestResponse.md with sample code which doesn't compile.

I guess both problems apply to more than just the one mentioned library.

Could you please fix these problems? Thanks!

_{(I did not review the whole PR. So when the described problems are fixed, further review is necessary.)}

[Nicklas2751]

@martin-mfg org.openapitools.client.model.TestResponse.CustomTypeAdapterFactory shouldn't exists and org.openapitools.client.model.TestResponse should be an interface.

I added another test to JavaClientCodegenTest with the OpenAPI schema you named and it worked. But when I use the CLI it doesn't work like you said. I added some more test but couldn't recreate the problem. But then I saw that I missed to regenerate the CLI Jar so I cleared the target folder and ran ./mvnw clean package again. Now the CLI works correctly too.

This is how I started the CLI:

java -jar modules/openapi-generator-cli/target/openapi-generator-cli.jar generate \
  -i https://github.com/OpenAPITools/openapi-generator/raw/fef84d956e23dad2cb6ef49b0519b7427a13857a/modules/openapi-generator/src/test/resources/3_0/typescript-fetch/oneOf.yaml \
  -g java \
  --library okhttp-gson \
  --additional-properties useOneOfInterfaces=true \
  -o test/okhttp-gson

tl;dr I had to regenerate the CLI then it generated the Interface as expected and without any compile errors.

[Nicklas2751]

@martin-mfg The second problem was in the doc generation of jersey2, jersey3 and native. I fixed it & added an test for it :)

[martin-mfg]

tl;dr I had to regenerate the CLI then it generated the Interface as expected and without any compile errors.

It seems we get different results, or maybe we're talking about different things. So I extended a unit test to show the problem I get - please see martin-mfg@554bb00. The test fails, as seen in this pipeline.

As you said, org.openapitools.client.model.TestResponse.CustomTypeAdapterFactory indeed doesn't exist. But still it is being referenced from src/main/java/org/openapitools/client/JSON.java.

[Nicklas2751]

@martin-mfg Ah, I see! Added another test for it & fixed it :)

[Nicklas2751]

@martin-mfg ping 🔔 :)

[Nicklas2751]

I got the newest changes from master branch and cleaned up the commit history of this branch.

@martin-mfg Is there anything I can do to make it easier for you to review this?

[martin-mfg]

Hi, Sorry for the delay. I am rather busy at the moment.

I tested the changes with the okhttp-gson library and this input spec. The generated output contains a few problems:

• TestObject implements neither MyOperationRequest nor MyOperation200Response
• It's unclear how to convert a String array to MyOperationRequest or how to convert MyOperation200Response to a number array.
• The readme contains example code including this line:

   MyOperationRequest myOperationRequest = new MyOperationRequest(); // MyOperationRequest | 

  Since MyOperationRequest is an interface, new MyOperationRequest() doesn't work.

I guess these problems apply also to some other libraries in addition to okhttp-gson.

Could you please fix these problems? Thanks!

^{(I did not review the whole PR. So when the described problems are fixed, further review is necessary.)}

---

@martin-mfg Is there anything I can do to make it easier for you to review this?

Don't feel obligated to get an approval from me specifically. It's totally fine if wing328 approves and merges this PR directly. Or if any other member of the Java technical committee approves this PR.

It might also be helpful if you do more testing of special cases on your own. You could look at some existing OpenAPI files, the OpenAPI documentation or the OpenAPI specification and try if the most relevant features work in combination with your useOneOfInterfaces changes.

Finally, we can also discuss a bit more via Slack.
Invitation link for account creation: https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA
Link to my Slack profile: https://openapi-generator.slack.com/team/U051HB9A0FJ

[dariuszzzlukasik]

+1

[tomasfrtala]

@wing328 any updates on this? I tested this for JavaJaxRS spec, and it works like a charm ;-) Thank you, guys, for your good work!

[Nicklas2751]

@tomasfrtala The change for the README which @martin-mfg requested is pretty hard since I don't know in the README template if useOneOfInterfacce is used or not. :/

[Nicklas2751]

@martin-mfg I created a new issue for the useless interface which is generated for oneOf with array types: #23494

I decided to create a new issue since the main goal of this PR is to support the useOneOfInterfaces option for all java generators