[Java] fix invalid valueOf() usage in enum templates

[jorgerod]

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.

Technical Committee

@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)

Description

This supersedes #21055, which had become unmergeable (conflicting with master) and whose author is no longer available. As requested by @wing328 (comment), this is a fresh PR based on the current master. Full credit to @timon-sbr and @martin-mfg (kept as co-authors of the original commit).

Scope update: after an early review, the PR was narrowed down to the Java restclient, resttemplate and webclient libraries. Those are the only generators that consume the shared Java/modelEnum.mustache and Java/modelInnerEnum.mustache templates; every other Java generator (microprofile, native, okhttp-gson, helidon, micronaut, JaxRS/cxf, Groovy...) uses its own copies under Java/libraries/, which are unchanged in this PR.

Problem

In Java/modelInnerEnum.mustache, the Java enum templates wrapped every enum value with {{dataType}}.valueOf(...):

{{{name}}}({{^isUri}}{{dataType}}.valueOf({{/isUri}}{{{value}}}{{^isUri}}){{/isUri}})

valueOf() is not available for every possible data type, which produces code that does not compile:

• BigDecimal has no BigDecimal.valueOf(BigDecimal) — e.g. type: number enums.

• UUID has no valueOf either. AbstractJavaCodegen.toEnumValue already returns UUID.fromString("...") for UUID enums, so the template emitted UUID.valueOf(UUID.fromString(...)). This mirrors URI, which was already excluded.

• Object has no valueOf at all — e.g. an inline enum: without an explicit type, or a type: string enum with additionalProperties: false, which currently map to Object:

  public enum OrderStatusEnum {
    PENDING(Object.valueOf("PENDING")),   // does not compile
    PROCESSING(Object.valueOf("PROCESSING"));

Fix

Two changes in each of the two shared templates:

1. Constructor (modelInnerEnum.mustache only): valueOf() is now only emitted for types that actually provide it, i.e. it is skipped for isUri, isUuid, isNumeric and isFreeFormObject:

   {{{name}}}({{^isUri}}{{^isUuid}}{{^isNumeric}}{{^isFreeFormObject}}{{dataType}}.valueOf({{/isFreeFormObject}}{{/isNumeric}}{{/isUuid}}{{/isUri}}{{{value}}})

   (As a visible consequence, numeric enums now emit NUMBER_1(1) instead of Integer.valueOf(1); Boolean/String keep using valueOf(), so this is non-breaking. The wrapper was originally added to fix Boolean enums, [JAVA] fix inner enums of booleans #19815.)

2. fromValue (both templates): numeric enums (isNumber, e.g. BigDecimal) are now compared with compareTo() instead of equals(), because BigDecimal.equals is scale-sensitive (1 != 1.0 numerically identical values would throw IllegalArgumentException at deserialization):

   {{^isString}}{{^isNumber}}b.value.equals(value){{/isNumber}}{{#isNumber}}value != null && b.value.compareTo(value) == 0{{/isNumber}}{{/isString}}

   For free-form-object enums (isFreeFormObject), the raw equals() comparison is kept.

3. JSON-B serializer (both templates): generator.write(obj.value) does not compile for enums backed by Object (jakarta.json.stream.JsonGenerator has no write(Object) overload); the value is now written as String.valueOf(obj.value) when isFreeFormObject.

Only modelEnum.mustache and modelInnerEnum.mustache (the shared templates used by restclient, resttemplate and webclient) are modified.

Test coverage

The shared petstore test spec (petstore-with-fake-endpoints-models-for-testing.yaml) gained:

• Order.paymentMethod — a numeric (type: number) enum, covering the BigDecimal case.
• Order.OrderStatus — a type: string enum with additionalProperties: false, covering the Object case.
• enum_form_integer / enum_form_double form parameters on testEnumParameters.

Samples were regenerated for the in-scope generators; all changes are limited to generated EnumTest model files.

This PR closes #20188 and replaces #21055.

[cubic-dev-ai]

1 issue found across 265 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="samples/client/petstore/java-helidon-client/v3/mp/src/main/java/org/openapitools/client/model/Order.java">

<violation number="1" location="samples/client/petstore/java-helidon-client/v3/mp/src/main/java/org/openapitools/client/model/Order.java:66">
P2: The newly added numeric inner enum PaymentMethodEnum cannot round-trip its wire value. Its constant names NUMBER_1/NUMBER_2 diverge from the spec values "1"/"2", and the java-helidon enumClass.mustache template emits no @JsonValue/@JsonCreator, so Jackson's name-based default serializes PaymentMethodEnum.NUMBER_1 as "NUMBER_1" and throws on deserializing "1". The standalone numeric enum OuterEnumInteger in the same sample carries @JsonValue/@JsonCreator and round-trips correctly, so the two are inconsistent. Add the @JsonValue/@JsonCreator (fromValue) pattern to the inner enum template, matching enumClass/standalone enums, so the new numeric enum test case is functional rather than compile-only.</violation>
</file>

<sub>Note: This PR contains a large number of files. cubic selects up to 200 of the highest-priority eligible files for this review, so some files may not have been reviewed.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 292 files

<sub>Note: This PR contains a large number of files. cubic selects up to 200 of the highest-priority eligible files for this review, so some files may not have been reviewed.

Re-trigger cubic</sub>

[cubic-dev-ai]

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

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

Re-trigger cubic</sub>

[cubic-dev-ai]

No issues found across 39 files

_{Re-trigger cubic}