[jpfinne]

fix #24769, fix #19194

Improve resolution of DefaultCodegen.getDiscriminatorType by resolving the best common type in all mapped discriminators.

Matching $ref types are used. Otherwise the types enum, integer, string, object are used.

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

Fixes #24769 and #19194 by inferring Java oneOf discriminator getter types from all mapped schemas instead of defaulting to Object. Constant string discriminators now generate Enum getters, while Kotlin keeps its existing string behavior.

• Resolves discriminator properties through $ref and allOf schemas.
• Preserves shared integer, number, and referenced enum types, with String or Object fallbacks when no common type exists; Java gains an enum mapping to Enum.
• Adds regression coverage for Java and Spring generators, including enum-valued discriminators.

^{Written for commit 93051c9. Summary will update on new commits.}

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 4 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 3 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[wing328]

Was able to repeat the issues locally and confirmed this PR addresses the issue

[jglick]

@jpfinne @wing328 this has not been released yet, but appears to break compilation in my project (currently using 7.25.0) when I tried using the master version of this repo while reproducing an unrelated issue (#24942). target/generated-sources/openapi/io/jenkins/plugins/cursor_origin_branch_source/origin_openapi/model/RulesetBypassActorInput.java (for example) contains

…
import io.jenkins.plugins.cursor_origin_branch_source.origin_openapi.model.Enum; // ←
…
  /**
   * Gets or Sets bypassMode
   */
  public enum BypassModeEnum {
    RULESET_BYPASS_MODE_UNSPECIFIED(Enum.valueOf("RULESET_BYPASS_MODE_UNSPECIFIED")),
    
    ALWAYS(Enum.valueOf("always")),
    
    PULL_REQUEST_ONLY(Enum.valueOf("pull_request_only"));

    private Enum value;

    BypassModeEnum(Enum value) {
      this.value = value;
    }

    @JsonValue
    public Enum getValue() {
      return value;
    }

    @Override
    public String toString() {
      return String.valueOf(value);
    }

    @JsonCreator
    public static BypassModeEnum fromValue(Enum value) {
      for (BypassModeEnum b : BypassModeEnum.values()) {
        if (b.value.equals(value)) {
          return b;
        }
      }
      throw new IllegalArgumentException("Unexpected value '" + value + "'");
    }
  }
…

If I comment out the noted import, under the assumption you meant java.lang.Enum, then more of it compiles, but not the Enum.valueOf(String) calls (there is an overload taking (Class<T>, String)). It was not really clear to me what this PR was supposed to be doing and therefore whether the fault lies somewhere in my project. I can file a bug report for it if you were not already aware. (#24838 sounds somehow related, but has merge conflicts so I cannot verify.)

[Mattias-Sehlstedt]

The change was targeted towards the issue where a discriminator has its alternatives define their discriminator value as an enum. This means that the alternatives will have a field with an enum, while the parent could not previously define a shared method referencing the enum (since it is technically unique per implementor).

The change then attempted to make the parent carry an Enum, so that the alternatives could implement the interface method. E.g.

components:
  schemas:
    Pet:
      oneOf:
        - $ref: '#/components/schemas/Cat'
        - $ref: '#/components/schemas/Dog'
      discriminator:
        propertyName: type
        mapping:
          CAT: '#/components/schemas/Cat'
          DOG: '#/components/schemas/Dog'
    Cat:
      description: A representation of a cat
      type: object
      properties:
        type:
          type: string
          const: CAT
        huntingSkill:
          type: string
      required:
        - type
        - huntingSkill
    Dog:
      description: A representation of a dog
      type: object
      properties:
        type:
          type: string
          const: DOG
        packSize:
          type: integer
          format: int32
      required:
        - type
        - packSize

A reduced specification that would include your broken class and any related schemas (e.g., any oneOf or allOf relations) would be helpful to scope the issue.

[jglick]

I am afraid I did not really follow any of that, and I did not write the specification, I am just consuming it. All I know is that the project compiles under 7.25.0, and fails to compile as of this PR.

[Mattias-Sehlstedt]

It does not matter whether you have written the specification or not. It is needed since it is helpful for reproducing and verifying the issue.

[jpfinne]

@jglick No need for the full specification. Try to give evidence with the smallest subset possible

[jglick]

Tried to do so in #24950. I hope that is legible; I really know nothing about OpenAPI.