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

Ouverte
  • Quelque chose ne va pas ?
#25,642 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@vinirib y travaille déjà.

Depuis le 13/11/2026.

  • #25648 par @vinirib — ouverte
  • #25649 par @rajeshvasa — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
java, spring
Domaine
backend, build-system

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Issue: Bug
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<>();
  1. 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.

Langage dominant
Java
Étoiles
26.9k
Forks
7.8k
Merge moyen
2 j 10 h
PR mergées (30 j)
180

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de OpenAPITools/openapi-generator

Toutes les issues de OpenAPITools/openapi-generator

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.