[BUG][JAVA][SPRING] instantiationTypes ignored in add…Item/put…Item helpers since 7.26.0, models no longer compile with custom typeMappings

Start by reviewing PRs #25001, #25648, and #25649, then trace the Java and Spring pojo.mustache templates that render add<Name>Item and put<Name>Item helpers. Reproduce with the supplied OpenAPI schema and generation options, then compare the generated helpers with the configured instantiationTypes. Done means the generated Java models compile and use the configured container types when helpers initialize null fields.

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator?
• 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

Since 7.26.0 the add<Name>Item and put<Name>Item helper methods of generated Java models always create an ArrayList or a HashMap. They no longer use the type configured with instantiationTypes. The field initializer still uses the configured type, so the two places in the same class disagree.

When typeMappings maps the container to a type that ArrayList or HashMap does not implement, the generated model does not compile. Our case is map=SequencedMap with instantiationTypes map=LinkedHashMap:

private SequencedMap<String, String> entries = new LinkedHashMap<>();

public Basket putEntriesItem(String key, String entriesItem) {
  if (this.entries == null) {
    this.entries = new HashMap<>();   // 7.25.0: new LinkedHashMap<>()
  }
  this.entries.put(key, entriesItem);
  return this;
}

Basket.java:41: error: incompatible types: cannot infer type arguments for HashMap<>
      this.entries = new HashMap<>();
                                ^
    reason: no instance(s) of type variable(s) K,V exist so that HashMap<K,V> conforms to SequencedMap<String,String>
Basket.java:70: error: incompatible types: cannot infer type arguments for ArrayList<>
      this.tags = new ArrayList<>();
                               ^
    reason: no instance(s) of type variable(s) E exist so that ArrayList<E> conforms to Deque<String>

The effect is not limited to custom type mappings. With only --instantiation-types map=LinkedHashMap set, the field is declared as Map<String, String> entries = new LinkedHashMap<>() and the code compiles. But when the field is null at the time putEntriesItem is called (after setEntries(null), or after deserializing "entries": null), the helper now creates a HashMap, where 7.25.0 created a LinkedHashMap. From then on the map no longer keeps insertion order, although the option asks for it.

openapi-generator version

Regression. 7.25.0 is correct. 7.26.0, 7.27.0 and 7.28.0-SNAPSHOT (build 20261111.130840-62) are affected.

Reproduced with the spring and the java generator. #25001 changed the same lines in the other Java pojo.mustache templates, so I expect them to be affected as well.

OpenAPI declaration file content or url

openapi: 3.0.3
info:
  title: instantiation types
  version: 1.0.0
paths: {}
components:
  schemas:
    Basket:
      type: object
      properties:
        entries:
          type: object
          additionalProperties:
            type: string
        tags:
          type: array
          items:
            type: string

Generation Details

java -jar openapi-generator-cli.jar generate \
  -i spec.yaml -g spring -o out \
  --type-mappings map=SequencedMap,array=Deque \
  --instantiation-types map=LinkedHashMap,array=ArrayDeque \
  --import-mappings SequencedMap=java.util.SequencedMap,LinkedHashMap=java.util.LinkedHashMap,Deque=java.util.Deque,ArrayDeque=java.util.ArrayDeque \
  --global-property models

The same options with -g java show the same result.

Steps to reproduce

1. Generate with the spec and command above.
2. Open out/src/main/java/org/openapitools/model/Basket.java.

Expected, as generated by 7.25.0:

this.entries = new LinkedHashMap<>();
this.tags = new ArrayDeque<>();

Actual since 7.26.0:

this.entries = new HashMap<>();
this.tags = new ArrayList<>();

3. Compile the model with JDK 21 or later: the two errors shown above.

Related issues/PRs

• #25001 (fix for #24993) introduced the change. I found no existing report.

Suggest a fix

Before #25001 the helpers rendered {{{defaultValue}}} and fell back to the literal type only when no default existed:

this.{{name}} = {{{defaultValue}}}{{^defaultValue}}new {{#uniqueItems}}LinkedHashSet{{/uniqueItems}}{{^uniqueItems}}HashMap{{/uniqueItems}}<>(){{/defaultValue}};

#25001 removed {{{defaultValue}}} from this line, so only the hard-coded type is left. My guess at the reason: defaultValue is not always an empty container. When the schema has a default, it is a container filled with those values (for example new ArrayList<>(Arrays.asList("red", "blue"))), and the helper needs an empty one.

The helper should create an empty container of the type set in instantiationTypes. The templates cannot see that type today. The generator could pass it to them as a new property, and the templates would keep ArrayList and HashMap for the case where no instantiation type is set.