[BUG][JAVA] Fix generation of complex default values (fixes #24993)

[jorgerod]

Closes: #24993

Type of change

This is primarily a bug fix: complex default values in OpenAPI specs (nested arrays/objects, oneOf schemas with defaults, nullable fields, containers) previously generated non-compilable Java code (see #24993).

As part of making the generation correct, default rendering was also extended where it silently produced invalid or incomplete output (e.g. date library specific defaults), so minor parts of this PR could be considered new behavior. I'm happy to split any feature-like part into a separate PR if the maintainers prefer smaller, atomic changes.

Problem

Given an OpenAPI spec with complex default values, e.g.:

components:
  schemas:
    NestedArrayWithDefaultValues:
      type: object
      properties:
        matrix:
          type: array
          default:
            - [1, 2]
            - [3, 4]
        pet:
          oneOf:
            - $ref: '#/components/schemas/Pet'
            - $ref: '#/components/schemas/Tag'
          default:
            name: Rex

the previous generator output for Java clients was syntactically invalid Java, such as:

private List<List<Integer>> matrix = new ArrayList<>(Arrays.asList(Arrays.asList(1, 2), [3, 4]));

or a default that referenced a schema class without constructing it, resulting in compile errors in the generated samples.

Root cause

The default-value rendering path in AbstractJavaCodegen only supported scalar defaults. When the default was a complex structure (arrays, nested arrays, objects, oneOf branches, date/time values), the renderer emitted fragments that could not be compiled.

Fix

• Extracted the complex default construction logic into a focused JavaDefaultValueRenderer component (following the pattern of other util components), so AbstractJavaCodegen keeps only the generator policy/configuration and delegates recursive default rendering through an explicit context (schema resolution, Java naming/type conversion, collection construction, date-library configuration, oneOf handling).
• Correct default rendering for:
  • arrays and nested arrays (List/Set, Arrays.asList(...), LinkedHashSet for uniqueItems)
  • object defaults and oneOf branch selection
  • date/time libraries (java8, threetenbp, joda, legacy java.util.Date)
  • nullable / optional fields with and without defaults
  • container initialization (previously broken for Map-like and nested containers)
• Updated affected generator mustache templates and regenerated all impacted Java samples.

Tests

• New directed unit tests in JavaClientCodegenTest, SpringCodegenTest and JavaPlayFrameworkCodegenTest covering arrays/objects defaults, oneOf branch selection, date libraries, nullable defaults and container initialization.
• Regenerated samples are committed so CI can verify the generator outputs of the HEAD commit.

Affected generators

Java-based generators that share AbstractJavaCodegen / the updated pojo.mustache templates: java client libraries (okhttp-gson, jersey2/3, resttemplate/webclient, native, rest-assured, feign, microprofile, helidon, retrofit2), spring (boot/declarative), JavaJaxRS, java-msf4j-server, and JavaPlayFramework.

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

[cubic-dev-ai]

All reported issues were addressed across 4 files

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

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 1 file (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 474 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.
Requires human review: Auto-approval blocked because this review re-detected 2 unresolved issues already reported by Cubic.

Re-trigger cubic</sub>

[Mattias-Sehlstedt]

I’d strongly recommend moving the default-construction logic into its own dedicated component rather than keeping it in AbstractJavaCodegen. That class already carries quite a bit of responsibility, so separating this into a more focused unit would likely make the design easier to manage, reason about, and extend/mimic. So similar to other Util components that have been introduced.

[cubic-dev-ai]

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

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

Re-trigger cubic</sub>

[jorgerod]

@Mattias-Sehlstedt Thanks for the suggestion. I agreed that the complex default construction logic was becoming too large for AbstractJavaCodegen, so I extracted it into a focused JavaDefaultValueRenderer component in follow-up commit d8b7b798d77.

AbstractJavaCodegen now keeps the generator policy/configuration and delegates recursive default rendering through an explicit context containing schema resolution, Java naming/type conversion, collection construction, date-library configuration, and oneOf handling. This keeps the renderer reusable and makes the rendering logic easier to test without duplicating generator behavior.

The existing functional regressions remain covered, including arrays/objects, oneOf branch selection, date libraries, nullable defaults, and container initialization. The directed Java/Spring/Play tests pass and checkstyle passes.

[cubic-dev-ai]

All reported issues were addressed across 93 files

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

Re-trigger cubic</sub>

[cubic-dev-ai]

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

<sub>Requires human review: Auto-approval blocked because this review re-detected 1 unresolved issue already reported by Cubic.
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 1 file (changes from recent commits).

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

Re-trigger cubic</sub>

[wing328]

thanks for the PR. let's give it a try