[Java] Render object default for composed ($ref + default) schemas (#23795)

[seonwooj0810]

Fixes #23795

Problem

When a property is declared as a $ref to an object schema with a sibling default (or, equivalently, an explicit allOf), the swagger-parser represents it as a composed schema — the object's properties live in the allOf members rather than directly on the schema.

AbstractJavaCodegen.toDefaultValue(...) handled this in the isComposedSchema(...) branch by falling through to super.toDefaultValue(schema), which emits the raw default value as Java:

private Nested test = {"one":"one","two":"two"};   // does not compile

The semantically-equivalent inline-object spec already rendered correctly:

private DtoTest test = new DtoTest().one("one").two("two");

Change

• Extracted the existing object-default rendering into a private toObjectDefaultValue(cp, defaultValue, propertySchemas) helper (behaviour-preserving for the plain isObjectSchema path).
• In the composed-schema branch, resolve the effective property schemas from the allOf members (dereferencing $refs) via a new getComposedSchemaProperties(...) helper, then render the default through the same fluent-builder logic.
• When no object properties can be resolved, return null instead of emitting uncompilable output — so the previously broken cases now at worst omit the default rather than producing code that fails to compile.

For the reporter's spec this now generates:

private Nested test = new Nested().one("one").two("two");

Tests

Added AbstractJavaCodegenTest.toDefaultValueForComposedObjectWithDefaultTest, which builds a composed (allOf → $ref) schema with an object default and asserts the rendered fluent-builder expression.

Tests run: 66, Failures: 0, Errors: 0, Skipped: 0
  -- in org.openapitools.codegen.java.AbstractJavaCodegenTest

Verification done: ran the modules/openapi-generator module test class AbstractJavaCodegenTest (JDK 21) — all 66 tests pass, including the pre-existing toDefaultValueTest that exercises the refactored object-default path, confirming no behaviour change there.

I did not run the full ./bin/generate-samples.sh regeneration: this code path only triggers for the composed-$ref-plus-default pattern, which previously produced uncompilable output, so no committed sample relies on the old behaviour and a regeneration is not expected to change any sample. Happy to regenerate any specific generator samples if a maintainer would like that included.

PR checklist

• Read the contribution guidelines.
• Ran full ./mvnw clean package + sample regeneration (see note above — targeted module tests run instead).
• Filed against master.

---

Summary by cubic

Fix Java generator to render object defaults for composed ($ref + default or allOf) schemas as fluent builder expressions instead of raw JSON, preventing uncompilable code. Addresses #23795.

• Bug Fixes
  • Resolve properties from allOf (dereferencing $ref) and render defaults via the object builder path; now generates new Nested().one("one").two("two").
  • Extracted toObjectDefaultValue(...) and getComposedSchemaProperties(...); plain object behavior unchanged.
  • If no properties are resolved, omit the default (return null) instead of emitting invalid Java.
  • Added AbstractJavaCodegenTest.toDefaultValueForComposedObjectWithDefaultTest; existing tests remain green.

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

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[Mattias-Sehlstedt]

I would argue that it would be more logical to entirely opt-out of generating a default value for these scenarios that do not work rather than attempting to fix them. Default values should not be sent by a client. Default values are strictly values that the server applies itself if the client has entirely omitted a value for an optional field.

So in order for the client to auto-adjust for any changes to the default, then it needs to not send anything, because if it does, then it will drift from the actual server default.

[seonwooj0810]

Thanks for the thoughtful point.

I agree with the API semantics you described: a server-side default is what the server applies when the client omits the value, and clients generally should not send generated defaults just to mirror the server.

My reason for keeping this PR in the “fix the rendered default” direction is that Java generation already has an existing behavior for object defaults: plain object schemas are rendered as a compilable fluent-builder expression. The bug here is that the same effective object schema becomes a composed schema when it is expressed as $ref + sibling default / allOf, and that path currently falls through to raw JSON that does not compile. So this PR tries to make the composed-object path consistent with the existing plain-object path, while returning null rather than emitting invalid Java when the object properties cannot be resolved.

If maintainers prefer to opt out of generating model defaults for this category altogether, I can adjust the PR. I would lean toward doing that as a broader Java default-generation policy change rather than only disabling the composed-schema case, otherwise $ref + default and equivalent inline object defaults would behave differently.

[wing328]

I prefer fixing the default values as some use cases simply generate the models (not the API files).