Problems with enum naming and validation

[andruskutt]

Hello,

I have two problems with enums:

• not unique name generated for values "_1A", "_2A". Names are out of my control

I'm trying to create workaround using mapping configuration enum-type: string which causes next problem

• @values annotation is created into List - List<@values(values = {"_1A", "_1B", "_2A"}) String> body
  But @values annotation @target does not contain TYPE_USE and code does not compile

openapi definition:

openapi: 3.0.3
info:
  title: test enum parameters
  version: 1.0.0

paths:

  /endpoint:
    post:
      tags:
        - enum
      requestBody:
        content:
          "application/json":
            schema:
              type: array
              items:
                $ref: '#/components/schemas/Foo'
      responses:
        '204':
          description: Empty

components:
  schemas:

    Foo:
      type: string
      enum:
        - _1A
        - _1B
        - _2A

mapping configuration:

openapi-processor-mapping: v12

options:
  package-name: generated

  target-dir:
    layout: standard

  generated-annotation: false
  json-property-annotation: auto
  format-code: false

  bean-validation: jakarta

  model-type: default
  model-accessors: false

  # generates duplicate enum names
  enum-type: default
  # generates @Values annotation into List, but @Values @Target does not include TYPE_USE
  # enum-type: string
map:
  types:
    - type: array => java.util.List

[hauner]

Hmm, strange that the enum identifiers removes the numbers.

The underscore is detected as a "word break" character. Since the word before the underscore is empty, the underscore is removed. Since a number is not a valid start character it should be prefixed with "v" (simply a hardcoded prefix) and then changed to uppercase because of the enum name convention.

So I would expect V1A, V2B and V2A.

The enum-type: string creates funny code... :-( I only have a test for using the string enum as a simple single parameter. Guess I never tried it with array.

I will look at it.

[andruskutt]

If we are at @values validating, then IMHO better validator is like that (assuming validator instances are used multiple times):

public class ValueValidator implements ConstraintValidator<Values, String> {
    private Set<String> values;

    @Override
    public void initialize (Values constraintAnnotation) {
        values = Set.copyOf(Arrays.asList(constraintAnnotation.values()));
    }

    @Override
    public boolean isValid (String value, ConstraintValidatorContext context) {
        return value != null && values.contains(value);
    }
}

• avoid object allocation in validation path
• Set is better data structure for contains()
• Set.copyOf(Arrays.asList(constraintAnnotation.values())) is to avoid IllegalArgumentException of Set.of(constraintAnnotation.values())

[hauner]

adding TYPE_USE makes it compile.

Thanks for mentioning it, it probably saved me some time searching for it :-)

Thanks also for the Validator suggestions.

[hauner]

fixed in 2025.3.1