[BUG][Java][Spring] JsonNullable generated for schemas using oneOf/anyOf

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

References to some types are unnecessarily wrapped in JsonNullable, even though nullable: true isn't used. This happens for types generated from schemas that use oneOf or anyOf to list allowed combinations of required properties like this:

      type: object
      properties:
         # ....
      oneOf:
        - required: [propertyA]
        - required: [propertyB]

A workaround for this problem is to add type: object to each of the oneOf subschemas.

openapi-generator version

Since version 7.x including 7.6.0-SNAPSHOT, doesn't occur in 6.x versions.

OpenAPI declaration file content or url

reproducer OpenAPI (+ extract of generated code):
https://gist.github.com/pvdbosch/1f26142fd9df792f7cba6cdff88dbc29

Generation Details

generatorName: spring
inputSpec: src/main/resources/openapi.yaml
additionalProperties:
  useSpringBoot3: true
  useBeanValidation: true
  interfaceOnly: true
  skipDefaultInterface: true
  dateLibrary: java8

Also occurs when using java generator with spring library. Doesn't reproduce for jaxrs-spec generator.

Steps to reproduce

1. Generate code using openapi.yaml
2. generated ReferencingSchema.java has an unneccessary JsonNullable wrapper for its content attribute.

Related issues/PRs

Suggest a fix

My guess is that the generator sets isNullable to true on the schema in this code because the type is missing in the oneOf subschemas ; though I haven't been able to confirm this yet.

This shouldn't be done however because there is a type defined in the schema that includes the oneOf.

Start with the referenced DefaultCodegen.java location and the reproducer gist, then generate the Spring output using the listed options and inspect ReferencingSchema.java. Compare the oneOf/anyOf schema handling with the generated JsonNullable field; done means the wrapper is absent when nullable is not used while the existing Spring and Java generation cases remain correct.