[cpruijsen]

Fixes #25398

A oneOf interface whose discriminator is an inline enum declared PetTypeEnum getPetType() without declaring PetTypeEnum. Each implementor declared a separate nested enum. The interface did not compile, and the implementor enums could not satisfy its getter.

The interface now declares the inline enum, and implementors reuse the inherited nested type.

Changes:

• AbstractJavaCodegen keeps interface-owned inline enums and clears isEnum on interface properties collected from implementors. It also clears the flag on discriminator copies pushed into implementors. The [REQ] [Java] Allow excluding discriminator property from generated models #24769 implementor-owned case is unchanged. Groovy is excluded because it does not render Java oneOf interfaces.
• Java, Spring, JAX-RS Spec, Micronaut, and Helidon interface templates render an enum when isEnum and isDiscriminator are set. JAX-RS also renders the required Jackson, JSON-B, or XML imports.
• Documentation uses isInnerEnum, so copied properties retain their enum type and values after isEnum is cleared.
• Spring and JAX-RS regression tests use bugs/issue_25398.yaml. No new vendor extension is added.

Implementation choice: shared Java post-processing covers every Java interface template. A Spring-only pass would be smaller but would leave the same defect in Java, JAX-RS Spec, and Micronaut. Repairing the pre-existing class-based oneOf hierarchy in native, okhttp-gson, Jersey, and Helidon is outside this change.

Checks:

• Affected generator suites: 1376 tests, 0 failures, 0 errors.
• checkstyle:check: BUILD SUCCESS.
• Both new regression tests fail on merge-base and pass on this change.
• Nineteen interface-based generator and library configurations type-check with javac. JAX-RS also type-checks with JSON-B and XML.
• The generated Spring project compiles 8 source files. On merge-base it fails because PetTypeEnum is missing.
• Groovy output compiles on master and on this change.
• Java and Micronaut Dog.md retain the enum type and values.
• All sample configurations and the generator docs regenerate with no committed changes.

PR checklist

• Read the contribution guidelines.

• 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.

  I ran ./bin/generate-samples.sh ./bin/configs/*.yaml and ./bin/utils/export_docs_generators.sh with this change. Neither changed a committed file, so the PR has no sample changes.

• 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 @sreeshas @jfiala @lukoyanov @cbornet @jeff9finger @karismann @Zomzog @lwlee2608 @martin-mfg @KannaKim (Java)
@cachescrubber @welshm @MelleD @atextor @manedev79 @javisst @borsch @banlevente (Java Spring)

[cubic-dev-ai]

All reported issues were addressed across 15 files

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

[jpfinne]

@cpruijsen Thanks for this PR.
I started an implementation in DefaultCodeGen protected CodegenDiscriminator createDiscriminator(String schemaName, Schema schema). A really complex task...

As I'm only interested at a fix for java and Spring, your PR is probably simpler.

You update AbstractJavaCodegen so the implementation should be valid for all java generators.
Can you add {{>modelInnerEnum}} in JavaSpring/oneof_interface.mustache and in java/oneof_interface.mustache?

[cpruijsen]

Thanks! java/oneof_interface already includes {{>modelInnerEnum}}. JavaSpring has no modelInnerEnum partial, so it uses {{>enumClass}}, same as JavaSpring/pojo.mustache.