[BUG] [JAVA] [Spring] Minimum/maximum parameters are written in scientific notation in JSR-301 annotations

[thegli]

Bug Report Checklist

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

Description

With model 'spring' and OAS 2 spec, the values in the generated JSR-301 annotations for "minimum" and "maximum" parameters for the items of an array are written in scientific notation. So instead of expected:

  @Valid
  private Set<@Min(100) @Max(200)Integer> numberlist = new LinkedHashSet<>();

the following is generated, which is not valid Java code:

  @Valid
  private Set<@Min(1E+2) @Max(2E+2)Integer> numberlist = new LinkedHashSet<>();

This problem does NOT occur:

• if the (semantically) same spec is in OAS 3 format
• for properties that are not items of an array (see "magicnumber" in the example)

openapi-generator version

Tried with 7.17.0, but also with 7.2.0 and many in-between releases. It does not look like a regression to me but more like a "never worked as expected" situation (?)

OpenAPI declaration file content or url

OAS 2 spec - this one causes the scientific notation output for the "numberlist" array property:

swagger: '2.0'
info:
  title: MinMax Bug Sample
  version: '1'

paths:
  /minmaxbug:
    post:
      operationId: demonstrateMinMaxBug
      produces:
        - application/json
      consumes:
        - application/json
      parameters:
        - in: body
          name: request
          required: true
          schema:
            $ref: '#/definitions/Foo'
      responses:
        '201':
          description: 'List of numbers created'
          schema:
            $ref: '#/definitions/Foo'

definitions:
  Foo:
    type: object
    required:
      - numberlist
      - magicnumber
    properties:
      numberlist:
        type: array
        minItems: 1
        maxItems: 10
        uniqueItems: true
        items:
          type: integer
          format: int32
          minimum: 100
          maximum: 200
          example: 123
      magicnumber:
        type: integer
        format: in32
        minimum: 300
        maximum: 400
        example: 345

OAS 3 spec - this one generates proper Java code for "numberlist":

openapi: 3.0.1
info:
  title: MinMax Bug Sample
  version: "1"

paths:
  /minmaxbug:
    post:
      operationId: demonstrateMinMaxBug
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Foo'
        required: true
      responses:
        "201":
          description: List of numbers created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Foo'

components:
  schemas:
    Foo:
      required:
      - numberlist
      type: object
      properties:
        numberlist:
          minItems: 1
          maxItems: 10
          uniqueItems: true
          type: array
          items:
            type: integer
            format: int32
            minimum: 100
            maximum: 200
            example: 123
        magicnumber:
          type: integer
          format: in32
          minimum: 300
          maximum: 400
          example: 345

Generation Details

Used the latest release of the CLI generator, with minimal parameters (see next section).

Steps to reproduce

java -jar openapi-generator-cli-7.17.0.jar generate -i ./oas2.yaml -o ./output/oas2/ 
-g spring -p useSpringBoot3=true

Related issues/PRs

A similar issue where scientific notation is also unexpectedly generated was posted just recently: https://github.com/OpenAPITools/openapi-generator/issues/22341

Suggest a fix

No fix at hand - I looked at *beanValidationCore.mustache - but it could be a type-conversion-chain issue like "string -> large number object such as BigDecimal -> to-string-method-that-prefers-scientific-notation".

[yuvi-chavan]

Hi, I would like to work on this issue. I have experience with Java, Spring Boot, and backend logic, and I’m familiar with numeric formatting behavior in BigDecimal. Could someone point me to the relevant code area where number formatting for annotations occurs (e.g., beanValidationCore.mustache or related templates)? I’d like to investigate and submit a PR for this fix. Thanks!