[JAVA] Reproducer for issue 23527

[winklerm]

Provides a reproducer test and a draft of the fix (probably not applicable in general, see the issue) for #23527.

The problem can be observed when trying to generate java client code for GeoJSON specification, let's see a simplified case:

• parent GeoJsonObject containing only type property also used in the discriminator and oneOf,
• child schemas:
  • Polygon containing coordinates property of type array of double,
  • MultiPolygon containing coordinates property of type array of arrays of double.

The generated GeoJsonObject parent class contains unexpectedly also the coordinates field with one of the above types, but the type cannot be overriden by one of the subclasses leading to compilation errors such as:

name clash: coordinates(List<Double>) in Polygon and coordinates(List<List<Double>>) in GeoJsonGeometry have the same erasure, yet neither overrides the other

I would expect the generated GeoJsonObject class not to contain any fields (coordinates in this case) which do not have the same type in the subclasses (alternatively, it could have a more generic type, but it is hard to say how that could be useful for different use-cases).

Happens to me with generator java and most libraries, the only two libraries which worked for me were okhttp-gson and jersey3, but our users would like to use apache-httpclient.

Suggest a fix

Please see the linked PR for a fix which works for our use-case, but I believe it cannot be applied as is to keep backward compatibility. It also breaks two tests:

[ERROR] org.openapitools.codegen.java.spring.SpringCodegenTest.allOfDuplicatedProperties -- Time elapsed: 0.044 s <<< FAILURE!
java.lang.AssertionError: No constructor with parameter(s) [String, Integer, Integer, String, String]
        at org.openapitools.codegen.java.assertions.JavaFileAssert.assertConstructor(JavaFileAssert.java:147)
        at org.openapitools.codegen.java.spring.SpringCodegenTest.allOfDuplicatedProperties(SpringCodegenTest.java:5182)
...

[ERROR] org.openapitools.codegen.ruby.RubyClientCodegenTest.allOfDuplicatedPropertiesTest -- Time elapsed: 0.002 s <<< FAILURE!
java.lang.AssertionError: expected [5] but found [3]
...

Perhaps a new configuration property could be introduced to disallow pulling up type-incompatible properties into the common parent class? Or is there a more systemic solution? I am also not sure where to put this functionality (DefaultCodegen vs AbstractJavaCodegen), I will be happy for any advice here.

@bbdouglas @sreeshas @jfiala @lukoyanov @cbornet @jeff9finger @karismann @Zomzog @lwlee2608 @martin-mfg

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 WSL)
  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 solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

---

Summary by cubic

Skip pulling up properties with conflicting types when merging oneOf sub-schemas into a parent model. This prevents ambiguous fields on discriminator bases and fixes Java generation errors for GeoJSON (e.g., coordinates name-clash).

• Bug Fixes
  • Updated DefaultCodegen.mergeProperties to drop properties that appear in multiple subtypes with incompatible types; added isSchemasTypeCompatible to compare base and nested array item types while keeping enum merging for type.
  • Added geojson_discriminator.yaml and DefaultCodegenTest.testGeoJsonObjectDoesNotContainCoordinates to verify that GeoJsonObject does not inherit coordinates from Polygon/MultiPolygon.
  • Added JavaClientCodegenTest.testGeoJsonObjectDoesNotContainCoordinates to assert GeoJsonObject.java omits coordinates while Polygon.java and MultiPolygon.java keep it.

^{Written for commit 05e276a. Summary will update on new commits.}

[winklerm]

I have also added a few tests indicating the problem at different levels (generic DefaultCodegen and JavaCodegen), please feel free to suggest what level is the most applicable for the proposed change.